library interaction within Modelsim

A

aclegg1986

Hi,

Is it allowable within VHDL + Modelsim to complie a package in the
work library and then reference that package within another library
(sim) as long as library work; use work.pkg_fpga.all is used in the
VHDL file? The reason I ask is because a Vcom -1195 error is reported
(i.e. work library does not contain the package), when I compile the
VHDL file into the sim library and the package is within the work
library. It's all fine when the package and file are in the same
library. One other observation is that when you choose the library to
compile to within the GUI work is listed twice, any ideas why this is
the case?

Thanks

Andy

Ps My Modelsim version is locked to Altera i.e pre compiled Altera
libraries
 
M

Mike Treseler

Hi,

Is it allowable within VHDL + Modelsim to complie a package in the
work library and then reference that package within another library
(sim) as long as library work; use work.pkg_fpga.all is used in the
VHDL file?

Not if you get a vcom error.

Modelsim sees a vhdl library as a directory path.
Quite often all of these directories are named
"work" but the paths are different.

If I say

use work.pkg_fpga.all

in my code, modelsim will look in ./work only.

If the package were really at a different path, say ./my_lib/work
I would have to say,

vmap my_lib/work work

before compiling.
Ps My Modelsim version is locked to Altera i.e pre compiled Altera
libraries

Only for gate level sims,
which you shouldn't really
need if you write your own code.

-- Mike Treseler
 
J

Jonathan Bromley

Hi,

Is it allowable within VHDL + Modelsim to complie a package in the
work library and then reference that package within another library
(sim) as long as library work; use work.pkg_fpga.all is used in the
VHDL file? The reason I ask is because a Vcom -1195 error is reported
(i.e. work library does not contain the package), when I compile the
VHDL file into the sim library and the package is within the work
library. It's all fine when the package and file are in the same
library. One other observation is that when you choose the library to
compile to within the GUI work is listed twice, any ideas why this is
the case?

To enlarge on what Mike said: In VHDL, the library name "work" has
a special meaning: it is an alias for the library into which
you are compiling stuff right now. In other words, if I have
a library "foo" and I direct the compiler to compile some
file into "foo" (for example, using the "-work" option to
ModelSim's compiler "vcom") then any reference within that
file to "work" is, in fact, a reference to "foo".

This picture is muddied by two other issues.

First, any VHDL tool can make its own choices about how
libraries in the file system (which, of course, are almost
always directories in any practical tool) should be given
VHDL library names. That "library mapping" is tool-specific.
In ModelSim you achieve it using the "vmap" command. However,
ModelSim also allows you a small short-cut: If you have a
library directory *in your current working directory*, and
that directory's name is a legal VHDL name (no spaces, only
letters and digits, the usual stuff) then ModelSim will accept
that library directory's filename as its VHDL library name too.

This is fine, and convenient, UNTIL you go and make a real
physical library called "work". ModelSim's project system
(on which be called down all the curses in the underworld)
does precisely this. I suspect this is why you've got two
"work" libraries in your GUI library view: one that's really
called "work", and one that is somewhere else but is currently
mapped to the logical name "work". If you value your sanity,
you should operate in one of these two ways:
- for very simple projects, create a library called "work"
and do EVERYTHING in it, relying on the fact that ModelSim
will use it by default;
- for more complicated projects, DO NOT AT ANY COST create
a physical library called "work" but instead create
libraries for each part of the project, and map each
in turn to "work" as you need to.
.... and never, never make use of ModelSim's project machinery.

So, when you reference something in "work" from within a
piece of VHDL code, you have no choice: that thing MUST
reside in the library into which you intend to compile
the source file that references it.

Hope this tidies things up a bit.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
(e-mail address removed)
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
 
M

Mike Treseler

Jonathan said:
If you value your sanity,
you should operate in one of these two ways:
- for very simple projects, create a library called "work"
and do EVERYTHING in it, relying on the fact that ModelSim
will use it by default;

My example assumed this simple library style.
Upsides to this style include:

1. Easiest for multiple designers to retain sanity.
2. Simple version control with svn or cvs.
3. Emacs vhdl-generate-makefile can cover the entire project.
4. No -lib clause or mapping needed on the command line.
just vcom my_file.vhd; vsim my_entity.vhd; etc
5. No librarian needed to enforce or fix up library references.

Downsides include:

1. Library unit names could clash.
2. Have to edit or map library references other than "work"
Hope this tidies things up a bit.

Yes, very good. Thanks.

-- Mike Treseler
 
M

Mike Treseler

Mike said:
4. No -lib clause or mapping needed on the command line.
just vcom my_file.vhd; vsim my_entity.vhd; etc
vsim my_entity; etc

-- Mike Treseler
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,982
Messages
2,570,185
Members
46,738
Latest member
JinaMacvit

Latest Threads

Top