Work library not same as current working library 
Author Message
 Work library not same as current working library

Example:

Compile entity foo into library work.
Compile entity foo into library other_lib.

bar.vhd contains:

library work;
use work.foo;

Compile bar.vhd into library other_lib.

Does "work.foo" in bar.vhd refer to work.foo, or other_lib.foo?

I have noticed inconsistent behaviour between the tools:

Modelsim and Simili see other_lib.foo

A popular synthesis tool (that shall remain nameless) sees work.foo.

Which is correct?
LRM Clause 11.2 seems a bit vague on the matter.

Note: if I leave out the line: "library work;" from bar.vhd, all tools
see other_lib.foo.

Thanks,
Allan.



Sun, 19 Dec 2004 18:11:06 GMT  
 Work library not same as current working library
Hi,
  Your question is very simple. When you compile your file, it places
them in WORK library by default. and so when you compile bar.vhd, it
would take foo from work library. If you want to use other_lib.foo,
then either include
use other_lib.foo or modify your modelsim.ini file to point work to
other_lib.
Arvind Kumar
Quote:

> Example:

> Compile entity foo into library work.
> Compile entity foo into library other_lib.

> bar.vhd contains:

> library work;
> use work.foo;

> Compile bar.vhd into library other_lib.

> Does "work.foo" in bar.vhd refer to work.foo, or other_lib.foo?

> I have noticed inconsistent behaviour between the tools:

> Modelsim and Simili see other_lib.foo

> A popular synthesis tool (that shall remain nameless) sees work.foo.

> Which is correct?
> LRM Clause 11.2 seems a bit vague on the matter.

> Note: if I leave out the line: "library work;" from bar.vhd, all tools
> see other_lib.foo.

> Thanks,
> Allan.



Mon, 20 Dec 2004 13:49:48 GMT  
 Work library not same as current working library

Quote:
>Hi,
>  Your question is very simple. When you compile your file, it places
>them in WORK library by default. and so when you compile bar.vhd, it
>would take foo from work library. If you want to use other_lib.foo,
>then either include
>use other_lib.foo or modify your modelsim.ini file to point work to
>other_lib.

Hi Arvind,

I don't think you understood my question.  Modelsim finds
other_lib.foo, not work.foo when I refer to work.foo in bar.vhd.

The other tool I mentioned does the opposite.  Surely they can't both
be right.

Thanks,
Allan.

Quote:

>> Example:

>> Compile entity foo into library work.
>> Compile entity foo into library other_lib.

>> bar.vhd contains:

>> library work;
>> use work.foo;

>> Compile bar.vhd into library other_lib.

>> Does "work.foo" in bar.vhd refer to work.foo, or other_lib.foo?

>> I have noticed inconsistent behaviour between the tools:

>> Modelsim and Simili see other_lib.foo

>> A popular synthesis tool (that shall remain nameless) sees work.foo.

>> Which is correct?
>> LRM Clause 11.2 seems a bit vague on the matter.

>> Note: if I leave out the line: "library work;" from bar.vhd, all tools
>> see other_lib.foo.

>> Thanks,
>> Allan.



Mon, 20 Dec 2004 14:45:24 GMT  
 Work library not same as current working library
Hi Allan,

    From LRM 11.2 I read:

Library logical name WORK denotes the current working library during a given
analysis.

So in your case given that you have specified your "current working library"
as other_lib it should refer to

other_lib.foo and NOT work.foo (where work is a physical directory name as
well and not just logical).

But as such Synthesis tools may fail to implement this as they *seem* to

they don't support Configurations ?).

Please do correct me if I am wrong.

HTH,
Srinivasan

--
Srinivasan Venkataramanan
ASIC Design Engineer
Software & Silicon Systems India Pvt Ltd. - an Intel company
Bangalore, India

I don't speak for Intel

Quote:
> Example:

> Compile entity foo into library work.
> Compile entity foo into library other_lib.

> bar.vhd contains:

> library work;
> use work.foo;

> Compile bar.vhd into library other_lib.

> Does "work.foo" in bar.vhd refer to work.foo, or other_lib.foo?

> I have noticed inconsistent behaviour between the tools:

> Modelsim and Simili see other_lib.foo

> A popular synthesis tool (that shall remain nameless) sees work.foo.

> Which is correct?
> LRM Clause 11.2 seems a bit vague on the matter.

> Note: if I leave out the line: "library work;" from bar.vhd, all tools
> see other_lib.foo.

> Thanks,
> Allan.



Mon, 20 Dec 2004 23:04:17 GMT  
 Work library not same as current working library

Quote:
> -----Original Message-----

> Compile entity foo into library work.
> Compile entity foo into library other_lib.
> bar.vhd contains:
> library work;
> use work.foo;
> Compile bar.vhd into library other_lib.
> Does "work.foo" in bar.vhd refer to work.foo, or other_lib.foo?
> I have noticed inconsistent behaviour between the tools:
> Modelsim and Simili see other_lib.foo
> A popular synthesis tool (that shall remain nameless) sees work.foo.
> Which is correct?
> LRM Clause 11.2 seems a bit vague on the matter.

Because, I suspect, you have a library whose PHYSICAL name is "work".

Quote:
> Note: if I leave out the line: "library work;" from bar.vhd, all tools
> see other_lib.foo.

As indeed they should, because "work" should always be an alias for
"the library that I'm compiling into right now".

However, tools may also introduce their own idea of the current working
library, and are free to choose their own methods for mapping from
logical (VHDL) library names to physical (probably directory) names.
You can have a ball setting up circular mappings in ModelSim and watching
its stack blow up (or have they fixed that now???).  And you can
have many hours of innocent fun with hdl.var and cds.lib files.  Hence
the possibility that your "library work" clause has deflected the compiler
from its rightfully-ordained notion of the working library.

The m{*filter*}of the story is:  don't ever, not for anyone, create a
library whose real, physical name is 'work'.  That way lies madness!
--
Jonathan Bromley
HDL 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

Fax: +44 (0)1425 471573                           Web: http://www.*-*-*.com/

This e-mail and any  attachments are  confidential and Doulos Ltd. reserves
all rights of privilege in  respect thereof. It is intended for the use of
the addressee only. If you are not the intended recipient please delete it
from  your  system, any  use, disclosure, or copying  of this  document is
unauthorised. The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.



Mon, 20 Dec 2004 23:31:53 GMT  
 Work library not same as current working library
On Thu, 4 Jul 2002 16:31:53 +0100, "Jonathan Bromley"

Quote:

>> -----Original Message-----

>>=20
>> Compile entity foo into library work.
>> Compile entity foo into library other_lib.
>> bar.vhd contains:
>> library work;
>> use work.foo;
>> Compile bar.vhd into library other_lib.
>> Does "work.foo" in bar.vhd refer to work.foo, or other_lib.foo?
>> I have noticed inconsistent behaviour between the tools:
>> Modelsim and Simili see other_lib.foo
>> A popular synthesis tool (that shall remain nameless) sees work.foo.
>> Which is correct?
>> LRM Clause 11.2 seems a bit vague on the matter.

>Because, I suspect, you have a library whose PHYSICAL name is "work".

Hi Jonathan,

Actually, the problem happens even if I don't have a physical library
called work.
But by including the line:

library work;

I think the synthesiser is looking for one, which is why it can't find
other_lib.foo.

- Show quoted text -

Quote:
>> Note: if I leave out the line: "library work;" from bar.vhd, all tools
>> see other_lib.foo.

>As indeed they should, because "work" should always be an alias for
>"the library that I'm compiling into right now".=20

>However, tools may also introduce their own idea of the current working
>library, and are free to choose their own methods for mapping from=20
>logical (VHDL) library names to physical (probably directory) names.
>You can have a ball setting up circular mappings in ModelSim and =
>watching
>its stack blow up (or have they fixed that now???).  And you can=20
>have many hours of innocent fun with hdl.var and cds.lib files.  Hence
>the possibility that your "library work" clause has deflected the =
>compiler
>from its rightfully-ordained notion of the working library.

>The m{*filter*}of the story is:  don't ever, not for anyone, create a
>library whose real, physical name is 'work'.  That way lies madness!

I find it interesting that most VHDL tools seem to default to a
physical library called "work".  (E.g. Modelsim, Simili, etc.)
As a consequence, just about everyone I know who writes VHDL uses a
physical library called "work".

Summary: I can get all the tools I use to do the right thing as long
as I don't ever have the line:

library work;

in my code.  I'm going to modify our internal coding standard to
prohibit the use of that line....

Thanks,
Allan.



Tue, 21 Dec 2004 15:27:37 GMT  
 Work library not same as current working library
On Fri, 05 Jul 2002 07:27:37 GMT,

Quote:

>On Thu, 4 Jul 2002 16:31:53 +0100, "Jonathan Bromley"

>>> -----Original Message-----

>>>=20
>>> Compile entity foo into library work.
>>> Compile entity foo into library other_lib.
>>> bar.vhd contains:
>>> library work;
>>> use work.foo;
>>> Compile bar.vhd into library other_lib.
>>> Does "work.foo" in bar.vhd refer to work.foo, or other_lib.foo?
>>> I have noticed inconsistent behaviour between the tools:
>>> Modelsim and Simili see other_lib.foo
>>> A popular synthesis tool (that shall remain nameless) sees work.foo.
>>> Which is correct?
>>> LRM Clause 11.2 seems a bit vague on the matter.

>>Because, I suspect, you have a library whose PHYSICAL name is "work".

>Hi Jonathan,

>Actually, the problem happens even if I don't have a physical library
>called work.
>But by including the line:

>library work;

>I think the synthesiser is looking for one, which is why it can't find
>other_lib.foo.

>>> Note: if I leave out the line: "library work;" from bar.vhd, all tools
>>> see other_lib.foo.

>>As indeed they should, because "work" should always be an alias for
>>"the library that I'm compiling into right now".=20

>>However, tools may also introduce their own idea of the current working
>>library, and are free to choose their own methods for mapping from=20
>>logical (VHDL) library names to physical (probably directory) names.
>>You can have a ball setting up circular mappings in ModelSim and =
>>watching
>>its stack blow up (or have they fixed that now???).  And you can=20
>>have many hours of innocent fun with hdl.var and cds.lib files.  Hence
>>the possibility that your "library work" clause has deflected the =
>>compiler
>>from its rightfully-ordained notion of the working library.

>>The m{*filter*}of the story is:  don't ever, not for anyone, create a
>>library whose real, physical name is 'work'.  That way lies madness!

>I find it interesting that most VHDL tools seem to default to a
>physical library called "work".  (E.g. Modelsim, Simili, etc.)
>As a consequence, just about everyone I know who writes VHDL uses a
>physical library called "work".

The author of Simili contacted me and pointed out that the Simili GUI
does not allow the creation of a physical library called 'work'.
(I only use the command line tools, which is why I wasn't aware of
this feature.)

Regards,
Allan.



Thu, 23 Dec 2004 01:17:14 GMT  
 
 [ 7 post ] 

 Relevant Pages 

1. Application library works correctly but the executable not

2. Labview 6.0.2 Call Library Function not working

3. Call Library Function - Function not found in library

4. Does not work with TPS but works with DBF

5. 5.2 Network application works with 95, does not work with 98

6. Does the Autosave works in Excel , if not how to make it work in my program

7. how does the call library function works

8. Do shared libraries work on HPUX???

9. Is it a problem to use only one working library

10. how to make this library work ?

11. mysql tcl library working with tclkit for Windows

12. Library to work with JPEG

 

 
Powered by phpBB® Forum Software