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

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

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

so here it begins a list of libraries...

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

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

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

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

now it begins a section related to the compiler

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

while here's a section related to the simulator

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:

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 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

these

Yes, as described in their fine documentation.

to

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.

--------------------------------------- Posted through

On 09/08/2013 09:04, snipped-for-privacy@gmail.com wrote: []

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'! :-)

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.

from the reference manual:

-L ? (optional) Specifies the library to search for design units instantiated from Verilog and for VHDL default component binding. Refer to ?Library Usage? 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.

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).

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

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.

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.

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: []

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!).

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.

he

y,

th

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:

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.

I agree. But you are in controll of the files, so why are you bothered by t he second script. Just leave it away.

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 outfile

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.

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.

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.

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 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.

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. 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.

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) .

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.

(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.)

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

code

the

cannot

library,

with

don't

A key word here is 'formal', meaning that the resultant will be used for anything other than an informal engineering experiment. And 'from scratch' includes getting the files from the code repository, to ensure that you know which version of files are being used. We do safety-critical stuff here, so this is important. YMMV.

However, these days it takes but a few seconds to recompile all the files for a moderate-to-large-sized simulation, so what's not to like?

--------------------------------------- Posted through