ModelSim -> Error: xxxxx.vhd(n): Library yyyy not found

Hi Josy,

--- Quote Start ---

Actually I tried a small project to see how the Test Bench Writer (11.0sp1) would handle the unconstrained std_logic_vector. I attach a .qar. I included the std_logic_2D version in the .qar for reference.

--- Quote End ---

Ok, I see a project and source, but no simulation script.

How do you go about simulating this design in Modelsim? I typically use a sim.tcl script to build all the components and create Tcl procedures for the testbench, eg., I just posted a simple example in this thread:

http://www.alteraforum.com/forum/showthread.php?t=32386

But I want to know what you are doing, so I can reproduce the error you see.

Cheers,

Dave

Hi Dave,

I use the Nativelink: go to Tools-> Run EDA Simulation Tool -> EDA Gate Level Simulation

It will produce a .do script on the fly I believe.

Regards,

Josy

Hi Josy,

--- Quote Start ---

I use the Nativelink: go to Tools-> Run EDA Simulation Tool -> EDA Gate Level Simulation

It will produce a .do script on the fly I believe.

--- Quote End ---

Ok, I got a chance to look at the design again tonight. The machine I am working on has 10.1 installed, but the design bombs out looking for array_of_slv, I uncommented the CC_data_types.vhd line

Type array_of_slv is array (natural range <>) of std_logic_vector ;

which Quartus is ok with, but Modelsim ASE doesn't like it.

I'll try it tomorrow on my other machine which has 11.0sp1 installed and see if I can get to the error you were seeing.

Cheers,

Dave

Hi Dave,

It was ModelSIm choking on the std_logic_2D as well, I didn't try compiling the array_of_slv with Modelsim as I was using Gate Level simulation anyway and using the QII generated testbench with the 'funny' types.

Anyway I just worked my way around the one project by making a test-project and generate some data in there to drive the dut and then ran the internal simulator. After that I finished the 'real' project (combining this and another subproject plus a bunch of M4K) under Modelsim, again using Gate Level simulation.

I noticed that the Altera Modelsim version is only 6.6d where Mentor have 10.0c out. Maybe that version has decent VHDL 2008 support? But then we would have to spend some additional money.

I'll have to find the time to study your 'script' setup more closely, but I have to find a solution/workaround for my 'legacy' std_logic_2D code as well.

Thanks for all the support,

Josy

--- Quote Start ---

Modelsim 10+ has very good 2008 support.

--- Quote End ---

How come Altera make us do with 6.6d then? Do they have a deal with Mentor to seed a 'teaser'?

WARNING:

Even though the latest release of Modelsim could be better, its not always compatible with the Quartus simulation IP.

I had a case where the altsyncram RAM simulation model provided with Quartus only worked correctly with the version of Modelsim that shipped with that version of Quartus.

Here's my notes from the testbench I submitted as part of the SR:

--
-- 1. This testbench works fine when run from Modelsim ALTERA 6.1g
--    (ships with Quartus 7.2 and 8.0)
--
--    However, with Modelsim SE 6.3f, it fails. Writes to the RAM
--    show valid output data after the 2 clock pipeline, but then
--    the data goes to unknown state - even if the address does
--    not change. Byte-enables were asserted during reads, and it
--    made no difference.

The 'solution' was to use only a compatible version of Modelsim. (I never have looked at the difference between altsyncram components to see if the code was actually changed ...).

Cheers,

Dave

--- Quote Start ---

--- Quote Start ---

Modelsim 10+ has very good 2008 support.

--- Quote End ---

How come Altera make us do with 6.6d then? Do they have a deal with Mentor to seed a 'teaser'?

--- Quote End ---

--- Quote Start ---

Its always been like that. The altera version is only updated once every couple of years.

--- Quote End ---

Perhaps an apology is on order: Quartus II 11.1 comes with ModelSim ASE 10.0c!

--- Quote Start ---

The error:

Library cc_data_types not found.

can probably be resolved by

vmap cc_data_types rtl_work

I suspect that in the regmux code you have

library cc_data_types;

use cc_data_types.cc_data_types.all;

or something like that.

Modelsim is expecting to find these data types in that library, whereas your script compiles them into 'work'.

Alternatively you can

vlib cc_data_types

vmap cc_data_types cc_data_types

vcom -93 -work cc_data_types {C:/qdesigns/c-cam/bb/vhdl_packages/CC_Data_Types.vhd}

Or something pretty close to that ...

Cheers,

Dave

--- Quote End ---

Apparently the thing to do is to use the 'work' as the container for user packages also.

--library CC_Data_Types ;
--	use CC_Data_Types.CC_Data_Types.all ;
library work ;
	use work.CC_Data_Types.all ;

This keeps the ModelSim link happy, and Quartus is fine with it too. (I suppose I used the 'use library' in a non-standard way. I never understood this VHDL library idea anyway ..)

--- Quote Start ---

Apparently the thing to do is to use the 'work' as the container for user packages also.

--library CC_Data_Types ;
--    use CC_Data_Types.CC_Data_Types.all ;
library work ;
    use work.CC_Data_Types.all ;

This keeps the ModelSim link happy, and Quartus is fine with it too. (I suppose I used the 'use library' in a non-standard way. I never understood this VHDL library idea anyway ..)

--- Quote End ---

Argh, that's a horrible thing to do :)

Do you rebuild the lpm library, and altera_mf library, etc., every time you run Modelsim? No of course you don't. How then does Modelsim Altera know about these libraries ... through the magic of library mappings.

Think of Modelsim libraries as shared object libraries, like a DLL or .so file.

When you build a C program or C++ program, you link against the shared library, you do not build it each time.

The same analogy holds for Modelsim libraries (whether the language be VHDL or Verilog - VHDL just happens to be more specific about their use).

I don't have 10.0c installed just yet, but I'd be extremely surprised if library mapping is somehow broken :)

Library mappings are stored in modelsim.ini or in the project file .mpf. I personally don't use .mpf files, since you cannot change directory in the Tcl shell. If you type the command 'where' or 'echo $env(MODELSIM)' it will tell you where the library mapping file is. Open that file and look at the top section [Library], and you will see all the mappings.

vmap fred [pwd]/fred

will edit that file and create a mapping to the library fred. Now you can compile into that library via

vcom -work fred <some code>

or delete the mapping via

vmap -del fred

But the delete will only work if the library mapping is still working correctly ($env(MODELSIM) points to what it thinks is the mapping file). If the original modelsim.ini file the variable MODELSIM points to was read-only, modelsim copies it to your local folder as modelsim.ini, and then changes the variable MODELSIM to simply modelsim.ini (i.e., a relative path, rather than an absolute path). If you cd away from the folder containing the copy of modelsim.ini, then the library mappings will not be visible anymore (since MODELSIM uses a relative path, and modelsim.ini does not exist in the folder you just changed to). I find this feature rather annoying. Perhaps you have just stumbled on it too.

Cheers,

Dave