A design library is defined in the VHDL 1076 standard as "an implementation-dependent storage facility for previously analyzed design units". This rather loose definition has resulted in many different implementations in synthesis and simulation tools. In general, however, you will find that design libraries are used to collect commonly-used design units (typically packages and package bodies) into uniquely-named areas that can be referenced from multiple source files in your design.

 

In a typical simulation environment, you will specify to the simulator the library into which you want each design unit compiled (or analyzed, to use the terminology of the VHDL standard). If you do not specify a library, the design units are compiled into a default library named work.

 

For simple design descriptions (such as those that are completely represented within a single source file), you will use the work library exclusively and will not have to put much thought into how libraries are implemented in the set of tools you are using. When you use the work library exclusively, all you need to do is specify a use statement such as:

use work.my_package.all;

 

prior to each entity declaration in your design for each package that you have declared in your source file. (You do not have to place use statements prior to an architecture declaration if the corresponding entity declaration is preceded by a use statement.)

 

If, however, you choose to use named libraries in your designs (and you are encouraged to do so, as it can dramatically improve your design productivity), then you should follow a few simple rules to avoid compatibility problems when moving between different simulation and synthesis environments. First, you should not use the work library to contain packages that are shared between design units located in different source files. Although some simulation environments allow previously-compiled contents of the work library to be accessed at any time (such as during the separate compilation of a source file), this is not actually defined by the VHDL standard and may not work in other simulation and synthesis environments.

 

Some synthesis and simulation tools actually define the work library to be only those design units that are included in the source file currently being compiled. This is a simple rule of usage and is the recommended use of work.

 

To keep your use of libraries as simple as possible, it is recommended that you make consistent use of VHDL source file names and corresponding library file names, and avoid the use of work for all but the simplest packages.

 

Package Visibility

The library statement described in the previous section is used to load a library so that its contents are available when compiling a source file. However, the library statement does not actually make the contents of the specified library (the packages or other design units found in the library) visible to design units in the current source file. Visibility is created when you specify one or more use statements prior to the design units requiring access to items in the library.

 

The use statement is quite flexible. You can specify exactly which items within a package are to be made visible, specify that all items in a package are to be made visible, or specify that all items in all packages for a specific library are to be made visible. The following examples demonstrate some of the possible uses of use statements:

 

use mylib.my_package.all;  -- All items in my_package are visible

 

use mylib.my_package.dff;   -- Just using the dff procedure

 

use mylib.all;        -- Make everything in the library visible

 

In general, you will find that it is most convenient to place a library statement (one for each external library being used) at the beginning of your source file, and place use statements just prior to those design units requiring visibility of items in the library. To prevent compatibility problems as described above, you should avoid using work for shared packages or other design units that cross source file boundaries.

 

For clarity, it is recommended that you specify both the library and package name in your use statements, even if you are using all items in the library.