Package and Library

Notes

A package is a collection of definitions of data types, subprograms, constants etc. This is especially useful in teamwork situations where everyone should work with the same data types, e.g. the same orientation of a vector range. This simplifies the connection of the modules of different designers to the complete VHDL model later on. Necessary changes are also circularized immediately to all persons concerned.

It is possible to split a package into a header and a body section. The package header contains prototype declarations of functions or procedures, the definition of all required data types and so on. The actual implementation of the subprograms can be placed in the body section. This simplifies the compilation process, because only the usually rather short package header must be read in order to decide whether the current VHDL code conforms to the previous declarations/definitions.

A package is referenced by a use clause. After the keyword ’use’ follows the so called “selected name”. This name consists of the library name where the compiled package has been placed, the package name itself and the object name which will be referenced. Usually, the keyword ’all’ is used to reference all visible objects of the package.

Notes

All analysed objects as there are packages, package bodies, entities, architectures and configurations can be found in a library. In VHDL, the library is a logical name with which compiled objects can be grouped and referenced. The default library is called “work”. This logical name can be mapped to another logical library name as shown in the picture, but it has to be mapped to a physical path on a storing device eventually.

Usually, every designer operates within his own work library. Yet he can use units from other libraries which might hold data from former projects (PROJEKT_1 and PROJEKT_XY) or the current project packages (USERPACK). If another library than WORK is to be used, it will have to be made visible to the VHDL compiler. This is done with the library statement that starts with the keyword ’library’, followed by the logical name of the library. For example the library IEEE is commonly used because it contains standardized packages.

Notes

In the example, the design consists of four modules. The top level is the module MONITOR which uses three other submodules. These other modules are called CTRL, DATA_IN and DATA_OUT.

The data types for the data format that will be monitored are defined in a package P as the data types might be used in other design which communicate with this one. A separate package body has also been written. The package P is referenced by the entities MONITOR, DATA_IN and DATA_OUT as these three modules will use the new data types. The CTRL module will process control signals, only, which can be modelled with the predefined data types. The entities MONITOR, DATA_IN and DATA_OUT each have a architecture A. Two different architectures (SIM and GATE) exist for the entity CTRL. A configuration is necessary for the simulation.

Secondary units like package bodies and architectures are linked automatically to their primary units (package and entities). Other links have to be made explicitly. Therefore the package P needs to be referenced with a use clause before the entities are declared, while this is not necessary for the corresponding architectures. The assembly of the final design is made by the configuration, i.e. hierarchy errors like incompatible interfaces will be reported when the configuration is analysed. If several architectures exist for one entity, the configuration will also select the architecture that is to be used for the current simulation.

Notes

The sequence of compilation is predetermined by the dependency of model parts. If a dependency tree was built, one would have to compile from the lowest level of hierarchy to the top.

As secondary units rely on information given in their primary units (e.g. the interface signals have to be known for an architecture), they can only be compiled when the corresponding primary unit has already been compiled before. Consequently, primary units have to be analysed before their secondary units (entity before architecture, package header before package body).

The same reason applies for references. A package, for example, has to be analysed before an entity which references this package can be compiled, because the entity or its architecture(s) need the information about the data types, etc. The second rule is to compile modules which are referenced by others before the modules that are actually referencing it. Therefore the configuration, which builds up the design hierarchy, has to be analysed at last.