From: Adam Krolnik (adamk@cyrix.com)
Date: Fri Nov 13 1998 - 15:16:40 PST
Good afternoon:
<p>> One major limitation of these switches is that one currently cannot
> instantiate multiple copies of the same model into a design and simulate
> some instances from one module (example: RTL code) and other instances from
> another module (example: gate-level model) unless `uselib switches are
> added to the top-level source code or the gate-level module name is
> changed, also requiring modification to the top-level source code.
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.
<p><p>> 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!
> location. My understanding is that NT does not support symbolic links.
[ Doesn't NT suck! But I digress]
<p>> ===
> 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 don't really like using + to separate module names to be incorporated
into a library. It's hard to read (not english.)
>
> >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.
Adam Krolnik
Verification Engineer
Cyrix - NSC.
Richardson TX. 75085
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:53:02 PDT
and
sponsored by Boyd Technology, Inc.