[cross-post] vlib, vmap, vcom, how it all works...

Hi everyone,

I'm trying to understand the details of each individual step from my
source code to a running a postlayout simulation with ModelSim. I've
read several articles on what are the steps, I've also checked the
default run.do script which ModelSim uses to do everything, but on top
of *what* I need to do I'd appreciate to understand *why* I need to do
so and *which* are the control files I need to know.

The workflow I'm interested in is the following:

1. editing vhdl code
2. compilation
3. presynthesis simulation
4. synthesis
5. postsynthensis simulation
6. place&route
7. postlayout simulation

Step 1. is fairly easy, a text editor and I'm done (better be emacs!).
In order to perform 2. I need to use 'vcom' from ModelSim, but before
doing that I need to specify which is my library. In order to do that,
in the default run.do the following commands are executed:

$ vlib presynth
$ vmap presynth presynt
$ vmap igloo /path/to/igloo/library/from/actel

Now. While I understand the need to 'create' a library (BTW, what
happened to 'work'!) I was puzzled on the need to map the library, but
then I figured that when running vmap a modelsim.ini file is created for
ModelSim to look at at startup in order to know where to look for
libraries. To be more precise it would be 'vcom' that needs that piece
of information, correct?

If this is the case, when I need to run 5. I will need to grab the vhd
generated by the synthesis (why do I need a vhd and not the edf/edn
file?), create a postsynth library, map it and then compile in there the
file with all the necessary files for the testbench. Is that correct?

If this is correct, when moving on to 7. it seems that I need to get the
backannotated vhdl from the p&r tool, create a postlayout library, map
it and compile the vhdl in it with the associated testbench.

If I'm on track with this, then I'd like to continue with simulating in
batch mode (I'm mainly interested in regression tests automatically
started). Here's is one hit I've found on running vsim in batch mode:

https://ece.uwaterloo.ca/~ece327/protected/modelsim/htmldocs/mgchelp.htm#context=modelsim_se_user&id=16&tab=0&topic=NoNespecified

What is strange is the use of a test.do script which may severely affect
everything since I can ran whatever command in a do script... I'm not
sure how much I want to depend on that. The default run.do instead has
the following part:

[skip compilation section]
> vsim -L igloo -L presynth  -t 1ps presynth.testbench
> add wave /testbench/*
> run 1000ns
> log testbench/*
> exit

where I presume testbench is my top level testbench entity (what about
the architecture!?!). And I also presume that this run.do is called from
the ModelSim terminal, therefore I need to understand a little bit how
can I pass it through command line (-c option??).

It seems to me that these instructions could also be passed to vsim in
batch mode and have it logging waveforms in external files
(http://research.cs.berkeley.edu/class/cs/61c/modelsim/). For regression
testing maybe waveforms are not so much interesting and a report is more
useful, maybe with a coverage report as well, but before hitting that
phase I believe I'll be looking a lot at waves and I better be prepared
for being able to have them somewhere.

After all this rant I think I bored you already to death, but believe me
that while writing this article I checked and verified all my stupid
thoughts, ending up with knowing much more than what I did yesterday
night when I started writing...

I guess I will continue to post my reasoning as I proceed with this
quest, hoping not to annoy anyone :-). And of course if anybody notices
I'm falling off track please give me a shout!

Al

-- 
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[snipped]

ModelSim looks in either 'modelsim.ini' or (if you are using it)
'your_project.mpf' quite often, including for library mappings. Open these
files with a text editor (when ModelSim not running) and study them.

In your script which performs compilation you may want to include code to
delete-and-reinitialise libraries to ensure that you are using only the
latest code, for instance something like:

if { [file exists test] } {
  vdel -lib test -all
}
vlib -long test
vmap test test

Different code may be required if using ModelSim 10.2 or later.

For post-synthesis simulations and post-layout simulations you will need to
reference the libraries with the technology-specific primitives.

I recommend that you Read The Fine Manuals, both the User Guide and the
Reference Manual.
	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Hi Robert,

On 08/08/2013 15:48, RCIngham wrote:
> [snipped]
> 
> ModelSim looks in either 'modelsim.ini' or (if you are using it)
> 'your_project.mpf' quite often, including for library mappings. Open these
> files with a text editor (when ModelSim not running) and study them.

apparently mpf is not used. My modelsim.ini looks like this (my comments
included):

> [Library]
so here it begins a list of libraries...
> others = $MODEL_TECH/../modelsim.ini

this one is a library, but looks like another ini file. Does it work as
include?

> igloo = /opt/microsemi/Libero_v10.1/Libero/lib/modelsim/precompiled/vhdl/igloo

this is mapped with vmap igloo /bla/bla/bla

> syncad_vhdl_lib = /opt/microsemi/Libero_v10.1/Libero/lib/actel/syncad_vhdl_lib

this one here apparently is not found and I believe is not used anywhere.

> presynth = presynth
> postsynth = postsynth
> postlayout = ../designer/impl1/simulation/postlayout

as igloo above, these libraries are mapped from the path they belong to.

> [vcom]
now it begins a section related to the compiler

> VHDL93 = 93
> 
> NoDebug = 0
> Explicit = 0
> CheckSynthesis = 0
> NoVitalCheck = 0
> Optimize_1164 = 1
> NoVital = 0
> Quiet = 0
> Show_source = 0
> DisableOpt = 0
> ZeroIn = 0
> CoverageNoSub = 0
> NoCoverage = 0
> Coverage = sbcef
> CoverCells = 1
> CoverExcludeDefault = 0
> CoverFEC = 1
> CoverShortCircuit = 1
> CoverOpt = 3
> Show_Warning1 = 1
> Show_Warning2 = 1
> Show_Warning3 = 1
> Show_Warning4 = 1
> Show_Warning5 = 1

These details I ignore for the time being, I believe they can be easily
understood with the User Manual.

> [vsim]

while here's a section related to the simulator

> IterationLimit = 5000
> VoptFlow = 1

> [vlog]
[]
I do not use verilog, therefore I can safely skip this part as of now...


> In your script which performs compilation you may want to include code to
> delete-and-reinitialise libraries to ensure that you are using only the
> latest code, for instance something like:
> 
> if { [file exists test] } {
>   vdel -lib test -all
> }
> vlib -long test
> vmap test test

Uhm, I thought that bringing the project up-to-date was done by make,
simply checking at the files' timestamps. I understand that make cannot
guarantee that vcom does not write properly the 'object' in the library,
therefore your suggestion might be on the safe side. The only issue with
this approach is that I would need to recompile every time the whole
library.

In my run.do instead there's somewhat the contrary:

> if {[file exists presynth/_info]} {
>    echo "INFO: Simulation library presynth already exists"
> } else {
>    vlib presynth
> }

no need to recreate the whole project. If I remove the library I will
need than to recompile based on the missing 'object'. vmk creates
Makefile rules which are relative to empty files with the name of the
file being compiled. Every time the source is modified it will be also
recompiled and added to the library. This is fairly simple because it
allows me to do rules without the need to know what type of objects vcom
is generating.

OTOT I lately realized that if you organize the sources to have entities
and architectures (or packages definitions and bodies) on separate files
then you can drastically reduce the amount of dependencies and therefore
recompilation.

Am Donnerstag, 8. August 2013 15:19:27 UTC+2 schrieb alb:
> Hi everyone,
> 
> 
> 
> I'm trying to understand the details of each individual step from my
> 
> source code to a running a postlayout simulation with ModelSim. I've
> 
> read several articles on what are the steps, I've also checked the
> 
> default run.do script which ModelSim uses to do everything, but on top
> 
> of *what* I need to do I'd appreciate to understand *why* I need to do
> 
> so and *which* are the control files I need to know.
> 
> 
> 
> The workflow I'm interested in is the following:
> 
> 
> 
> 1. editing vhdl code
> 
> 2. compilation
> 
> 3. presynthesis simulation
> 
> 4. synthesis
> 
> 5. postsynthensis simulation
> 
> 6. place&route
> 
> 7. postlayout simulation
> 
> 
> 
> Step 1. is fairly easy, a text editor and I'm done (better be emacs!).
> 
> In order to perform 2. I need to use 'vcom' from ModelSim, but before
> 
> doing that I need to specify which is my library. In order to do that,
> 
> in the default run.do the following commands are executed:
> 
> 
> 
> $ vlib presynth
> 
> $ vmap presynth presynt
> 
> $ vmap igloo /path/to/igloo/library/from/actel
> 
> 
> 
> Now. While I understand the need to 'create' a library (BTW, what
> 
> happened to 'work'!) I was puzzled on the need to map the library, but
> 
> then I figured that when running vmap a modelsim.ini file is created for
> 
> ModelSim to look at at startup in order to know where to look for
> 
> libraries. To be more precise it would be 'vcom' that needs that piece
> 
> of information, correct?
> 
> 
> 
> If this is the case, when I need to run 5. I will need to grab the vhd
> 
> generated by the synthesis (why do I need a vhd and not the edf/edn
> 
> file?), create a postsynth library, map it and then compile in there the
> 
> file with all the necessary files for the testbench. Is that correct?
> 
> 
> 
> If this is correct, when moving on to 7. it seems that I need to get the
> 
> backannotated vhdl from the p&r tool, create a postlayout library, map
> 
> it and compile the vhdl in it with the associated testbench.
> 
> 
> 
> If I'm on track with this, then I'd like to continue with simulating in
> 
> batch mode (I'm mainly interested in regression tests automatically
> 
> started). Here's is one hit I've found on running vsim in batch mode:
> 
> 
> 
> https://ece.uwaterloo.ca/~ece327/protected/modelsim/htmldocs/mgchelp.htm#context=modelsim_se_user&id=16&tab=0&topic=NoNespecified
> 
> 
> 
> What is strange is the use of a test.do script which may severely affect
> 
> everything since I can ran whatever command in a do script... I'm not
> 
> sure how much I want to depend on that. The default run.do instead has
> 
> the following part:
> 
> 
> 
> [skip compilation section]
> 
> > vsim -L igloo -L presynth  -t 1ps presynth.testbench
> 
> > add wave /testbench/*
> 
> > run 1000ns
> 
> > log testbench/*
> 
> > exit
> 
> 
> 
> where I presume testbench is my top level testbench entity (what about
> 
> the architecture!?!). And I also presume that this run.do is called from
> 
> the ModelSim terminal, therefore I need to understand a little bit how
> 
> can I pass it through command line (-c option??).
> 
> 
> 
> It seems to me that these instructions could also be passed to vsim in
> 
> batch mode and have it logging waveforms in external files
> 
> (http://research.cs.berkeley.edu/class/cs/61c/modelsim/). For regression
> 
> testing maybe waveforms are not so much interesting and a report is more
> 
> useful, maybe with a coverage report as well, but before hitting that
> 
> phase I believe I'll be looking a lot at waves and I better be prepared
> 
> for being able to have them somewhere.
> 
> 
> 
> After all this rant I think I bored you already to death, but believe me
> 
> that while writing this article I checked and verified all my stupid
> 
> thoughts, ending up with knowing much more than what I did yesterday
> 
> night when I started writing...
> 
> 
> 
> I guess I will continue to post my reasoning as I proceed with this
> 
> quest, hoping not to annoy anyone :-). And of course if anybody notices
> 
> I'm falling off track please give me a shout!
> 
> 
> 
> Al
> 
> 
> 
> -- 
> 
> A: Because it fouls the order in which people normally read text.
> 
> Q: Why is top-posting such a bad thing?
> 
> A: Top-posting.
> 
> Q: What is the most annoying thing on usenet and in e-mail?

Hi Al,
you seem to make things much more complicated than they are.

Some simple hints:
To start modelsim from th ecommandline:
  vsim -do myscript.do

The -L option in vsim is for verilog simulations only, isn't it? 
You might let it away, unless you don't do mixed mode simulations.

If you don't explicitly mention an architecture in a vsim command, the first one is taken from the library.
Testbenches mostly have just one architecture anyway.
Design models often have multiple architectures for different implementation styles or other purposes (behavioral, structural_post_par etc.). 

When you create a local library, no vmap is needed.
 vlib my_library
is sufficient.
Also this can be done just once, because as you already have seen it is stored in the ini file.
If you are using libraries more often, like the vendor libraries, you should put them in a higher level ini file, so they are present for all your projects.
(Ini files are read in beginning from the modelsim install path, then the users home dir and finally the project dir. The first one is global but can be partly overwritten by the later ones)

The work library is normally local, so at the creation of a project you need to do a 
  vlib work
just once.
Then you have a default saving you from always mentioning some self created local library name.

By the way,
behavioral simulation (presyn) and timing simulation (post-par) make sense.
What's the benefit of a post-syn simulation?
Is it just to distinguish synthesis tool bugs from design bugs?

Have a nice simulation
  Eilert

>Hi Robert,
>
>On 08/08/2013 15:48, RCIngham wrote:
>> [snipped]
>> 
>> ModelSim looks in either 'modelsim.ini' or (if you are using it)
>> 'your_project.mpf' quite often, including for library mappings. Open
these
>> files with a text editor (when ModelSim not running) and study them.
>
>apparently mpf is not used. My modelsim.ini looks like this (my comments
>included):
>
>> [Library]
>so here it begins a list of libraries...
>> others = $MODEL_TECH/../modelsim.ini
>
>this one is a library, but looks like another ini file. Does it work as
>include?

Yes, as described in their fine documentation.

[snip]

>> In your script which performs compilation you may want to include code
to
>> delete-and-reinitialise libraries to ensure that you are using only the
>> latest code, for instance something like:
>> 
>> if { [file exists test] } {
>>   vdel -lib test -all
>> }
>> vlib -long test
>> vmap test test
>
>Uhm, I thought that bringing the project up-to-date was done by make,
>simply checking at the files' timestamps. I understand that make cannot
>guarantee that vcom does not write properly the 'object' in the library,
>therefore your suggestion might be on the safe side. The only issue with
>this approach is that I would need to recompile every time the whole
>library.

If you want to use 'make' (or 'vmake') I cannot assist further. We don't
use it here. Formal synthesis builds are ALWAYS done from scratch, and I
suspect that formal verification is similar.

[snip]
	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

On 09/08/2013 09:04, goouse99@gmail.com wrote:
[]
>> What is strange is the use of a test.do script which may severely
>> affect everything since I can ran whatever command in a do
>> script... I'm not sure how much I want to depend on that.
[]
> you seem to make things much more complicated than they are.

if you refer to the quoted text above then I may have lots of reasons
not to depend on a script that may interfere with my previously compiled
code. Placing compiler options in two separate scripts can
be confusing and IMO prone to errors. There should always be 'one source
of truth'! :-)

> 
> Some simple hints: To start modelsim from th ecommandline: vsim -do
> myscript.do

I'm interested in starting vsim in batch mode. Since I'm controlling my
flow with a makefile I tend to refrain from scattering my options around.

> 
> The -L option in vsim is for verilog simulations only, isn't it? You
> might let it away, unless you don't do mixed mode simulations.

from the reference manual:
-L <library_name> &#4294967295;
(optional) Specifies the library to search for design units instantiated
from Verilog and for VHDL default component binding. Refer to &#4294967295;Library
Usage&#4294967295; for more information. If multiple libraries are specified, each
must be preceded by the -L option. Libraries are searched in the order
in which they appear on the command line.

> If you don't explicitly mention an architecture in a vsim command,
> the first one is taken from the library. Testbenches mostly have just
> one architecture anyway.

I may have several architectures for several testcases (even though this
is not my preferred way). And any way, it seems I can pass either the
configuration or the entity/architecture pair as object arguments.
BTW, quoting the reference manual:

"The entity may have an architecture optionally specified; if omitted
the last architecture compiled." (not the first).

> When you create a local library, no vmap is needed. vlib my_library 
> is sufficient.

interesting. Does it mean that vcom looks always for the current
directory to look for libraries?

> Also this can be done just once, because as you already have seen it
> is stored in the ini file.

if no vmap is used than the library is not stored in the ini file. I did
a quick check: remove modelsim.ini from current directory, run vlib
mylib, no ini file created.

> If you are using libraries more often, like the vendor libraries, you
> should put them in a higher level ini file, so they are present for
> all your projects. (Ini files are read in beginning from the modelsim
> install path, then the users home dir and finally the project dir.
> The first one is global but can be partly overwritten by the later
> ones)

that's an interesting point. I got the impression that when using vmap
the first time a modelsim.ini was added to the local directory from the
modelsim install path and then modified accordingly.

[]
> By the way, behavioral simulation (presyn) and timing simulation
> (post-par) make sense. What's the benefit of a post-syn simulation? 
> Is it just to distinguish synthesis tool bugs from design bugs?

Actually, if I'm happy with my postsynth simulation I may skip the
post-par, provided that static timing analysis doesn't report any
violation. What else do you expect from your post-par simulation?
I still might be missing the point, but I do not see what is the benefit
of a post-par simulation (even though I included it in my workflow in
the OP).

Hi Robert,

On 09/08/2013 11:38, RCIngham wrote:
[]
>>> In your script which performs compilation you may want to include code
> to
>>> delete-and-reinitialise libraries to ensure that you are using only the
>>> latest code, for instance something like:
>>>
>>> if { [file exists test] } {
>>>   vdel -lib test -all
>>> }
>>> vlib -long test
>>> vmap test test
>>
>> Uhm, I thought that bringing the project up-to-date was done by make,
>> simply checking at the files' timestamps. I understand that make cannot
>> guarantee that vcom does not write properly the 'object' in the library,
>> therefore your suggestion might be on the safe side. The only issue with
>> this approach is that I would need to recompile every time the whole
>> library.
> 
> If you want to use 'make' (or 'vmake') I cannot assist further. We don't
> use it here. Formal synthesis builds are ALWAYS done from scratch, and I
> suspect that formal verification is similar.

I still do not grasp the reason behind compiling everything from
scratch. VHDL has clear dependencies and if you take care (as with a
makefile) about bringing all the dependencies up to date, why should you
synthesize everything again?

If we agree that a synthesis is a repeatable process, i.e. for a given
source of code+constraints it will always result in the same logic, then
I do not understand the need for building from scratch. If my assumption
is not the same, then again I wouldn't recompile something if I know it
works (if ain't broken don't fix it!).

On Saturday, 10 August 2013 00:30:07 UTC+1, alb  wrote:

>=20
> Actually, if I'm happy with my postsynth simulation I may skip the
>=20
> post-par, provided that static timing analysis doesn't report any
>=20
> violation. What else do you expect from your post-par simulation?
>=20
> I still might be missing the point, but I do not see what is the benefit
>=20
> of a post-par simulation (even though I included it in my workflow in
>=20
> the OP).

Last time I looked, Altera and XIlinx take different approaches to timing s=
imulation. Altera docs say FPGA designs are getting too large and timing si=
mulations take too long, so altera has dropped support for timing simulatio=
ns for its newer devices, and their docs state that you should use STA. Xil=
inx docs iirc state that timing simulation should be done because you can't=
 rely solely on STA for their FPGAs.

I don't know what Actel recommends.

On Saturday, 10 August 2013 00:53:40 UTC+1, alb  wrote:
> =20
> On 09/08/2013 11:38, RCIngham wrote:
>=20
> []
>=20
> >>> In your script which performs compilation you may want to include cod=
e
>=20
> > to
>=20
> >>> delete-and-reinitialise libraries to ensure that you are using only t=
he
>=20
> >>> latest code, for instance something like:
>=20
> >>>
>=20
> >>> if { [file exists test] } {
>=20
> >>>   vdel -lib test -all
>=20
> >>> }
>=20
> >>> vlib -long test
>=20
> >>> vmap test test
>=20
> >>
>=20
> >> Uhm, I thought that bringing the project up-to-date was done by make,
>=20
> >> simply checking at the files' timestamps. I understand that make canno=
t
>=20
> >> guarantee that vcom does not write properly the 'object' in the librar=
y,
>=20
> >> therefore your suggestion might be on the safe side. The only issue wi=
th
>=20
> >> this approach is that I would need to recompile every time the whole
>=20
> >> library.
>=20
> >=20
>=20
> > If you want to use 'make' (or 'vmake') I cannot assist further. We don'=
t
>=20
> > use it here. Formal synthesis builds are ALWAYS done from scratch, and =
I
>=20
> > suspect that formal verification is similar.
>=20
>=20
>=20
> I still do not grasp the reason behind compiling everything from
>=20
> scratch. VHDL has clear dependencies and if you take care (as with a
>=20
> makefile) about bringing all the dependencies up to date, why should you
>=20
> synthesize everything again?
>=20
>=20
>=20
> If we agree that a synthesis is a repeatable process, i.e. for a given
>=20
> source of code+constraints it will always result in the same logic, then
>=20
> I do not understand the need for building from scratch. If my assumption
>=20
> is not the same, then again I wouldn't recompile something if I know it
>=20
> works (if ain't broken don't fix it!).

Generally for consistancy in formal verification you build from scratch, ru=
n simulation, analyse results. Buggy build scripts are not _that_ uncommon.=
 Also if you're only checking timestamps, what happens when you change buil=
d options, do all your files get recompiled?

That's not to say you should take this approach with your projects. It depe=
nds on the nature of your project.

Hi Al

Am Samstag, 10. August 2013 01:30:07 UTC+2 schrieb alb:
> On 09/08/2013 09:04, goo...@mail... wrote:
>=20
> []
>=20
> >> What is strange is the use of a test.do script which may severely
> >> affect everything since I can ran whatever command in a do
> >> script... I'm not sure how much I want to depend on that.
>=20
As I understand, test.do is getting created automatically by some tool.
So why do you use it anyway if you already have your own scripts and a make=
file (as you mention later).
Just copy/paste the few things you think that might be useful in your own s=
cript and ignore the other one.

> []
>=20
> > you seem to make things much more complicated than they are.
>=20
> if you refer to the quoted text above then I may have lots of reasons
> not to depend on a script that may interfere with my previously compiled
> code. Placing compiler options in two separate scripts can
> be confusing and IMO prone to errors. There should always be 'one source=
=20
> of truth'! :-)
>=20
I agree. But you are in controll of the files, so why are you bothered by t=
he second script. Just leave it away.

> >=20
>=20
> > Some simple hints: To start modelsim from the commandline: vsim -do
> > myscript.do
>=20
> I'm interested in starting vsim in batch mode. Since I'm controlling my
> flow with a makefile I tend to refrain from scattering my options around.
>=20
Ok, I got that wrong. Thought you just wanted to start vsim from batch, but=
 missed that you also want to run it without the GUI appearing.

The documentation about this kind of batch mode states that you simply use =
i/o redirection for this purpose.

vsim tb_name <infile(.do) >outfile


>=20
> > The -L option in vsim is for verilog simulations only, isn't it? You
> > might let it away, unless you don't do mixed mode simulations.
>=20
> from the reference manual:
> -L <library_name> =85
> (optional) Specifies the library to search for design units instantiated
> from Verilog and for VHDL default component binding. Refer to =93Library
> Usage=94 for more information. If multiple libraries are specified, each
> must be preceded by the -L option. Libraries are searched in the order
> in which they appear on the command line.
>=20
I see. Seems like I never  needed the default binding stuff, so I never cam=
e across using -L with my VHDL Testbenches. Maybe Actel handles things diff=
erently.

>=20
> > If you don't explicitly mention an architecture in a vsim command,
> > the first one is taken from the library. Testbenches mostly have just
> > one architecture anyway.
>=20
>=20
> I may have several architectures for several testcases (even though this
> is not my preferred way). And any way, it seems I can pass either the
> configuration or the entity/architecture pair as object arguments.
> BTW, quoting the reference manual:

As you say for yourself, it's not your prefered way. I just wanted to point=
 out that the automatic generated script worked on such an assumption. Mayb=
e the programmer was just lazy.
Of course it is always better to tell the tool specifically which entity an=
d architecture to use. Either directly or via the configuration.

> "The entity may have an architecture optionally specified; if omitted
> the last architecture compiled." (not the first).
Thanks for looking this up.
In any way, if one just names the entity and has several architectures, the=
 tool might use the wrong one. So the assumption (only one arc. per tb) mad=
e by the Actel tool programmers is kind of careless and might only work wit=
hin the world of their own flow.=20

>=20
>=20
> > When you create a local library, no vmap is needed. vlib my_library=20
> > is sufficient.
>=20
>=20
> interesting. Does it mean that vcom looks always for the current
> directory to look for libraries?
>=20
vcom will look up the lib pathes from the ini file and (as wee will see bel=
ow) from the current directory too.

Actually vlib does not just take the name of a new library, but also the pa=
th.
So=20
  vlib my_lib
really means
  vlib ./my_lib
.
Therefore you can also create libraries elsewhere, rather than just the loc=
al directory.
Like
  vlib ~/somwhere/below/your/homedir/my_other_lib

vmap is mainly needed to switch between several versions of the same librar=
y. E.g. if some tool changes or updates require this. But it's a rare occas=
ion.

>=20
> > Also this can be done just once, because as you already have seen it
> > is stored in the ini file.
>=20
> if no vmap is used than the library is not stored in the ini file. I did
> a quick check: remove modelsim.ini from current directory, run vlib
> mylib, no ini file created.
>=20
I did that test too, and found out that even vmap does not create a local i=
ni file. It tries to access those in the modelsim install path. So, apart f=
rom the informations stored in the ini file modelsim seems to be able to fi=
nd libraries in the local directory all by itself.=20
While
  vlib nixus
will be recognized in vsim,
  vlib ../nullus
won't appear in the library list since it is placed in the parent directory=
.
Here a vmap or a manual entry to the ini file (e.g. in case of write protec=
tion by the admin) is needed.   =20

Never had problems to access some local libraries once they were created an=
d you really don't want your work library path always get updated in your m=
ain ini file. Just imagine what would happen on a multi user system with a =
central installation (were that file will be write protected anyway) .


>=20
> > If you are using libraries more often, like the vendor libraries, you
> > should put them in a higher level ini file, so they are present for
> > all your projects. (Ini files are read in beginning from the modelsim
> > install path, then the users home dir and finally the project dir.
> > The first one is global but can be partly overwritten by the later
> > ones)
>=20
>=20
> that's an interesting point. I got the impression that when using vmap
> the first time a modelsim.ini was added to the local directory from the
> modelsim install path and then modified accordingly.
That too, to give you some kind of template.
Still, even if you have no local ini file, modelsim knows all the library p=
athes when you start it. Guess from where, and don't forget that there is a=
 ~/modelsim.ini too.=20
>=20
(Besides, using vmap does not create some local ini file when I use it. But=
 this may be a version or installation specific difference if you happen to=
 see that behavior.)
>=20
> []
>=20
> > By the way, behavioral simulation (presyn) and timing simulation
> > (post-par) make sense. What's the benefit of a post-syn simulation?=20
> > Is it just to distinguish synthesis tool bugs from design bugs?
>=20
> Actually, if I'm happy with my postsynth simulation I may skip the
> post-par, provided that static timing analysis doesn't report any
> violation. What else do you expect from your post-par simulation?
> I still might be missing the point, but I do not see what is the benefit
> of a post-par simulation (even though I included it in my workflow in
> the OP).
That didn't answer the question about the benefit of the postsynth simulati=
on.

From some followup posts and other threads I know that the use of a timing =
simulation is under discussion. Mainly because of the long time it may take=
 for a large design.
STA gives you some valuable informations almost instantly, but it depends o=
n the assumption that your timing constraints are correct and complete.
It analyses the DUTs properties against their specs/constraints.
Still it does not tell how the DUT interacts with the external world.
An accurate timing simulation requires also the tb to do some kind of board=
 level simulation. No easy task, indeed. But the only way to check for inte=
rface problems between DUT and external devices before actually touching re=
al hardware.
It may be good to do at least some tests of the external interfaces rather =
than simulation the whole design with post-par simulations.


Have a nice simulation

  Eilert