Howto specify taget library for VHDL objects?

  • Thread starter Valentin Tihomirov
  • Start date
V

Valentin Tihomirov

Guest
A Quotation:
The library clause defines the logical names of design libraries, which are
used by the design units. A library is a storage facility for previously
analysed design units. In practice, this relates mostly to packages.
....
User-specified packages are stored in the working library WORK.
Examples:
library IEEE;
use IEEE.Std_Logic_1164.all;


That is, I can use analyzed objects residing in ANY library while all my
objects can go only into WORK library. Is it true? How can I control
destination library in VHDL file for the objects being analyzed? I have many
reasons to ask this question. One of them is the following. I have an entity
and its configuration in ONE vhdl file. Simulator shows the following error
message:
"Error: COMP96_0208: txunit_tb.vhd : (136, 1): For a configuration of a
given design entity, both the configuration declaration and the
corresponding entity declaration must reside in the same library"
Seems that entity and its configuration is compiled into a library different
from WORK. You see, I have no ideas how could I do that. In fact, I use
Avtive-HDL. All objects are compiled into a library having a name of my
project. THERE IS NO WORK LIBRARY!! Until using configuration, I have no
problem with direct instantiations like this
uut: entity work.E_NAME(A_NAME) ...
 
"Valentin Tihomirov" <valentin@abelectron.com> wrote in
message news:bob84b$1cbe91$1@ID-212430.news.uni-berlin.de...

The library clause defines the logical names of design libraries, which
are
used by the design units. A library is a storage facility for previously
analysed design units. In practice, this relates mostly to packages.
...
User-specified packages are stored in the working library WORK.

That is, I can use analyzed objects residing in ANY library while all my
objects can go only into WORK library. Is it true?
Yes.

How can I control
destination library in VHDL file for the objects being analyzed?
By telling the compiler which library to use as the destination.
WORK is not a real library. It is an alias for "the library
that I am compiling stuff into right now". For this reason,
it is a VERY bad idea to create a real library whose name is
WORK. (Are you listening, those folk who designed ModelSim's
project system ??!!)

In ModelSim, specifying the target library is an easy
command-line switch:

vcom -93 -work target_library some_file.vhd

My guess is that Aldec's "acom" command has a similar
switch, but I don't know it.

I have many
reasons to ask this question. One of them is the following. I have an
entity
and its configuration in ONE vhdl file. Simulator shows the following
error
message:
"Error: COMP96_0208: txunit_tb.vhd : (136, 1): For a configuration of a
given design entity, both the configuration declaration and the
corresponding entity declaration must reside in the same library"
Indeed. In the source code of a configuration, WORK is the library
into which the configuration is being compiled. The top-level
entity you're configuring must be in that same library.

Seems that entity and its configuration is compiled into a library
different
from WORK. You see, I have no ideas how could I do that. In fact, I use
Avtive-HDL. All objects are compiled into a library having a name of my
project.
In that case, I really can't see the problem... can you post the
minimum set of source code that exhibits this trouble?

THERE IS NO WORK LIBRARY!!
Yes, there is. The target of your current compilation, whatever
its logical name, is WORK. See my comments above.
--
Jonathan Bromley, Consultant

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

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail: jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573 Web: http://www.doulos.com

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


Seems that entity and its configuration is compiled into a library
different
from WORK. You see, I have no ideas how could I do that. In fact, I use
Avtive-HDL. All objects are compiled into a library having a name of my
project.

In that case, I really can't see the problem... can you post the
minimum set of source code that exhibits this trouble?




ENTITY Tx_Unit_TB_vhd_tb IS
END Tx_Unit_TB_vhd_tb;

ARCHITECTURE behavior OF Tx_Unit_TB_vhd_tb IS

COMPONENT transmitter
PORT(
Clk : in std_logic; -- Clock signal
.....
);
END COMPONENT;

.....
BEGIN

uut: transmitter PORT MAP(
-- uut: entity work.TX_UNIT(ARCH_X_BUFFER) PORT MAP( -- this works
Clk => Clk,
....
);

END;


configuration TX_TB_CFG of TxUnit_TB_vhd_tb is -- error message
for behavior
for uut: transmitter
use entity work.tx_unit(ARCH_X_BUFFER);
end for;
end for;
end TX_TB_CFG;







TX_UNIT had been compiled prelimilarily. In fact, I could not physically
compile the tx_unit enity and the configuration into different libraries
because the working lib is the only write-enabled. Is the message "For a
configuration of a given design entity, both the configuration declaration
and the corresponding entity declaration must reside in the same library"
appropriate?
 
"Valentin Tihomirov" <valentin@abelectron.com> wrote in
message news:bobl3i$1d2vpq$1@ID-212430.news.uni-berlin.de...

configuration TX_TB_CFG of TxUnit_TB_vhd_tb is -- error message
for behavior
for uut: transmitter
use entity work.tx_unit(ARCH_X_BUFFER);
end for;
end for;
end TX_TB_CFG;

TX_UNIT had been compiled prelimilarily. In fact, I could not physically
compile the tx_unit enity and the configuration into different libraries
because the working lib is the only write-enabled. Is the message "For a
configuration of a given design entity, both the configuration declaration
and the corresponding entity declaration must reside in the same library"
appropriate?

configuration TX_TB_CFG of TxUnit_TB_vhd_tb is
~~~~~ ^^^^^^^^^^^^^^^^
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^^THIS ENTITY^^
must already exist in the same library as the configuration.
Have you compiled entity TxUnit_TB_vhd_tb into the working
library? If not, the error message is completely sensible.

If you have, I don't know what's wrong. Try pasting the
configuration on to the end of the testbench source file,
so it gets compiled immediately after the test bench.
That might help to clarify what's happening.
--
Jonathan Bromley, Consultant

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

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail: jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573 Web: http://www.doulos.com

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

That is, I can use analyzed objects residing in ANY library while all my
objects can go only into WORK library. Is it true?
That the most common way to do it.
The standard libraries are used, but not compiled.
To see these settings, cd to your design directory
and type

amap (for aldec) (vmap for modelsim)

The source files under development are compiled
into vhdl library units that may be referenced by the
code, like this:

use work.mypackage.all

For such a reference to succeed, the local
library directory must be created at some point
using

cd <path to source>

alib mylib (vlib mylib for modelsim)

to create the dirctory mylib, then

amap work mylib (vmap work mylib for modelsim)

to bind the name "work" with the directory you just made.

The advantage to this binding, is that we don't need the
-work my_lib
clause when we compile. We can just say:

vcom my_file.vhd.

Note that you have to compile a unit before you use
it, so be careful if you have multiple units in
one file.

-- Mike Treseler
 
Valentin Tihomirov a écrit :

ENTITY Tx_Unit_TB_vhd_tb IS
END Tx_Unit_TB_vhd_tb;
...
ARCHITECTURE behavior OF Tx_Unit_TB_vhd_tb IS
...
configuration TX_TB_CFG of TxUnit_TB_vhd_tb is -- error message
...
Tipo? Your entity name is Tx_Unit_TB_vhd_tb and you're trying to configure
TxUnit_TB_vhd_tb (one _ less).

Regards,
--
Renaud Pacalet, GET/ENST/COMELEC/LabSoC
Institut Eurecom BP 193, 2229 route des Cretes
F-06904 Sophia-Antipolis Cedex
Tel : +33 (0) 4 9300 2770
Fax : +33 (0) 4 9300 2627
Fight Spam! Join EuroCAUCE: http://www.euro.cauce.org/
 
In fact, I use Avtive-HDL.
There is a newsgroup for Active-HDL users. It is hosted by Aldec. The
newsserver is www.aldec.com and the group's name is aldec.support.activehdl.

/Mikhail
 
Mike Treseler wrote:

Valentin Tihomirov wrote:

That is, I can use analyzed objects residing in ANY library while
all my objects can go only into WORK library. Is it true?

That the most common way to do it.
The standard libraries are used, but not compiled.
To see these settings, cd to your design directory
and type

amap (for aldec) (vmap for modelsim)

The source files under development are compiled
into vhdl library units that may be referenced by the
code, like this:

use work.mypackage.all

For such a reference to succeed, the local
library directory must be created at some point
using

cd <path to source

alib mylib (vlib mylib for modelsim)

to create the dirctory mylib, then

amap work mylib (vmap work mylib for modelsim)

to bind the name "work" with the directory you just made.

The advantage to this binding, is that we don't need the
-work my_lib
clause when we compile. We can just say:

vcom my_file.vhd.

Note that you have to compile a unit before you use
it, so be careful if you have multiple units in
one file.
IMHO this is a roundabout way. The big confusion here is that
"work" in "use work.mypackage.all" is not necessarily literally
a library called "work". In stead, it is de *working* library,
which is the library the current design unit is being stored
(compiled, analyzed) into. The name of that library is the name
that was given on the command line when invoking the analyzer
(e.g. vcom -work mylib myentity.vhd).

So, the following is the most simple and clean way (of course
still IMHO) to compile things in a specific library (for ModelSim):

% vlib my_lib
% vcom -work my_lib my_package.vhd
Model Technology ModelSim SE vcom 5.7d Compiler 2003.05 May 11 2003
-- Loading package standard
-- Compiling package my_package
% vcom -work my_lib my_entity.vhd
Model Technology ModelSim SE vcom 5.7d Compiler 2003.05 May 11 2003
-- Loading package standard
-- Loading package my_package
-- Compiling entity my_entity
%

Paul.

P.S.
Reading your posting once again, maybe the issue of "working
library" was not not the point you tried to make. You just
wanted to avoid typing "-work my_lib".

Oh well, I'll post it any way. If it makes one person think
about the issue, that's enough for me. :)
 
Paul Uiterlinden wrote:

So, the following is the most simple and clean way (of course
still IMHO) to compile things in a specific library (for ModelSim):

% vlib my_lib
% vcom -work my_lib my_package.vhd
Model Technology ModelSim SE vcom 5.7d Compiler 2003.05 May 11 2003
-- Loading package standard
-- Compiling package my_package
% vcom -work my_lib my_entity.vhd
Model Technology ModelSim SE vcom 5.7d Compiler 2003.05 May 11 2003
-- Loading package standard
-- Loading package my_package
-- Compiling entity my_entity
Yes, that is most simple, and in fact proves that the
vmap work my_lib
is not strictly necessary.

The only downside for me
(besides having to type -lib my_lib all the time :)
is that without an explicit
mapping of work = mylib, a leftover directory
actually having the magic name "work"
can cause great confusion as it will pick
up default vdir, vcom and vsim commands.

Reading your posting once again, maybe the issue of "working
library" was not not the point you tried to make. You just
wanted to avoid typing "-work my_lib".

Oh well, I'll post it any way. If it makes one person think
about the issue, that's enough for me. :)
I'm glad you pushed the send button.
It's a subtle point that
most have tripped over at least once.
And yes, it made at least one person think.

-- Mike Treseler
 

Welcome to EDABoard.com

Sponsor

Back
Top