From: Clifford E. Cummings (cliffc@sunburst-design.com)
Date: Mon Dec 07 1998 - 19:29:39 PST
On Nov 13, 1998, Adam Krolnik posed the following questions:
X-Lines: 233
Content-Type: text/plain; charset="us-ascii"
Content-Length: 9700
X-Status: $$$$
X-UID: 0000000739
Status: RO
>Another problem I believe posed in the same mail was:
>
>A new system is being built with new and old ASICs. The old ASICs
>instantiate modules and library components that may have names
>that conflict with the new design. Please provide the ability to
>specify how to compile one part of a design and be able to
>respecify how to compile the rest of the design.
I have added two different ASIC1 libraries, 1um and 0.35um to the
example directory structure and have included the example B05_cfg4
which instantiates two asics, the first uses the older 1um library
and the second uses the newer 0.35um library.
The new directory structure and example file will be sent as
separate e-mail messages.
------------------------------------------------------
>> Points of discussion include:
>>
>> ==========
>
>> I believe I heard support from Jay Lawrence to include file-
>> mapping in some form into the configuration enhancement proposal.
>>
>> Cadence Position: I believe Jay's position was that it should be
>> included in the library declaration (whatever form that takes) and
>> not in the configuration declaration itself.
>>
>> Cliff's Position: I currently would like to see this capability
>> permitted in both library and configuration declarations.
>
>I think this would provide the best flexibility. People don't have
>to embed paths in files that must be repositionable; people can
>embed paths into files to ease their life.
>
>And, again we say uselibdir, uselibfile. What really is a libdir,
>a libfile? This is what really needs to be defined whatever
>configurations we select!
My definition of a libdir and a libfile is somewhat dependent on
the type of simulator being used, interpreted (like Verilog-XL) or
compiled (like VCS or Modelsim).
Uselibfile
==========
For interpreted simulators:
uselibfile: acts just like the "-v" switch. The libfile is read
but the only modules that are compiled are the ones that are
required to run the simulation.
For compiled simulators:
uselibfile: acts similar to the "-v" switch. If not already
compiled, or if the library source file is newer than the compiled
libfile, then the libfile is read and compiled (or re-compiled)
and only the modules that are required to run the simulation are
linked into the simulation executable.
Uselibdir
=========
For interpreted simulators:
uselibdir: acts just like the "-y" switch with +libext command.
The libdir is scanned only for filenames that match the modules
that are required to run the simulation. Only these files are
compiled for use in the simulation.
For compiled simulators:
uselibdir: acts similar to the "-y" switch with +libext command.
If not already compiled, or if the libdir source files are newer
than the compiled libdir, then all of the files in the libdir are
read and compiled (or re-compiled) and only the modules that are
required to run the simulation are linked into the simulation
executable.
Summary - Today, Verilog simulators require the engineer to use
either "-v" and "-y" switches, or to specify a compiled library.
The above method can be used with both compiled code simulators
and interpreted simulators using the exact same syntax and "the
right thing happens."
------------------------------------------------------
>> location. My understanding is that NT does not support symbolic links.
>
>[ Doesn't NT suck! But I digress]
Digression welcome (and I agree ;-)
>> ===
>> 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
>> ==========
>>
>'Environment variables inversely follow the group rule "the more
>the better".'
>
>Why does one want an environment variable when you can produce a
>library definition file that could be devoid of paths and use
>relative references from the location of the library definition
>file to specify files and directories to be part of a library.
>
>E.g.
>
>% cat //root/projects/proj2/tb/vendor1lib.lib
>library vendor1lib;
> uselibfile ./core/ver/asic1.cfg:dsp1+dsp2+dsp3;
> uselibdir ./io/ver:v,
> ./lib/ver:v;
>endlibrary
>
>If these paths were relative to /root/projects/proj2/tb/ then you
>wouldn't need the environment variable (and the headache's.)
>
>Then you would only have to reference the vendor1lib.lib file -
>you could move the entire set of directories and only have to
>update where you reference it from.
>
>E.g.
>config asic1_gates;
> // No instance command therefore these libs are defaults
> uselib asic1_gates_lib; // to use files from gates dir
> uselib /root/project/ASIC1/vendor1lib; // to use dsp cores and all
other
>gates
>endconfig
I believe we do need environmental variables for the following scenarios:
Assumption - An ASIC library is typically installed in a central
location (because it is not unusual for an ASIC library to be
100's of megabytes in size (synthesis libraries, simulation
libraries, ASIC vendor tools, etc.)). I believe it is more common
to install an ASIC library in a central location than it is to
install the library in a user's directory. Many ASIC vendors
already require an install-directory environmental variable to run
the vendor tools. The same variable could be used for simulations.
Assumption - A file system might fill up requiring the ASIC
library to be moved to a new disk partition.
Assumption - Users might have multiple library configurations
using parts from the same library.
Assumption - A user might have to send the design files to an ASIC
vendor for support.
Assumption - A user might be sharing design files with another
company that is developing complimentary ASICs to go into the same
system.
Assumption - A user might be sharing design files with engineers
at another company location where the files are installed in a
different path (because the sysadmin at site #2 believes his
way of building directory structures is better than the way that
is used by the sysadmin at site #1).
Assumption - A sysadmin might have a common build script to
generate a user's directory structure with a root_protected .cshrc
file that calls one or more user and system .cshrc files. One of
these files might be a .cshrc_asiclibs file with all of the
environmental variables for ASIC library paths included. A
subsequent .cshrc_user file could be used to override defined
environmental variables for special situations and simulations.
I agree that environmental variables can be abused. I also believe
that environmental variables can be a tool. An environmental
variable is just that. A variable that defines where an ASIC
library is defined in a particular environment. I have either
supported or experienced all of the above scenarios where a simple
environmental variable as opposed to hard-coded directories would
have greatly facilitated simulating, sharing and supporting designs.
>I don't really like using + to separate module names to be
>incorporated into a library. It's hard to read (not english.)
I have no great desire to use "+" as a module separator. This
notation came from +libext+.v+.vg+.p, etc. If you would like to
propose an alternate syntax, please feel free.
------------------------------------------------------
>> >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:
>
>I have to believe you would also have port differences between a
>RTL and a gate model. E.g. unbussed ports. This is a real
>interesting problem - requires a wrapper; then you might as well
>add the parameters that do nothing.
It is quite common to write out gate-level models from synthesis
tools with instantiated I/O cells that are connected to Verilog
busses; hence, both RTL and gate-level designs do indeed have the
same bussed ports. One work-around to the missing parameter problem
is to write makefiles and scripts that add dummy parameter
definitions to all gate-level models. I was hoping for a more
elegant solution to this problem.
The problem with wrappers is that there is a significant
simulation performance penalty for passing data through a port
unless the design is flattened and the ports are collapsed.
Wrappers add an additional layer of ports and the corresponding
simulation penalties. This is one of my biggest complaints with
the Cadence developers that support the translation of Concept
schematics to Verilog models. Last year at the Cadence Users
Group, one of the Cadence marketing people outlined the new
Cadence strategy for translating Concept symbols into Verilog. The
strategy was centered on the proliferation of Verilog wrappers to
map symbols to models (Gag!)
> Adam Krolnik
- Cliff
<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:53:02 PDT
and
sponsored by Boyd Technology, Inc.