courses:system_design:project_management:name_spaces

Name Spaces

Introduction

package PKG is
  constant C : integer := 1;
end PKG;
 
use work.PKG.all;
entity ENT is
end ENT;
 
architecture RTL of ENT is
   signal C : integer := 8;
begin
     -- only signal C is visible
  C <= 24;
  process
     variable C : integer := 9;
  begin
     -- only variable C is visible
    C := 42;
    for C in 0 to 5 loop
     -- only loop parameter C
     -- is visible
            ENT.C <= C; -- selected
                        -- name
   end loop;
       ENT.C <= work.PKG.C;
  end process;
end RTL;
  • Multiple objects of same names allowed:
    • Without selected names: Local name overrides
    • Assignment with complete selected names: ENT.C ⇐ 12;
  • Declarations in …
    • a package are visible in all design units which use this package
    • an entity declarative part are visible in all the architectures of this entity
    • an architecture are visible for all processes of this architecture
    • a process are visible only inside this process
    • a loop statement or in a subprogram are only visible inside these objects.

Notes

While the library statement is always necessary, objects can be accessed via their “selected name” instead of a use clause.

Then, the complete logical path consisting of the names of the library, design unit and object must be specified.

Visibility problems may arise when libraries and packages are used because objects with identical names and parameter lists can be defined in several locations.

An illegal redeclaration error will be reported if objects with the same name and parameter lists are present within one VHDL file. If non distinguishable objects are referenced during compilation, none of the eligible objects is used and an error message is generated, even if the objects are identical.

Packages

  • Packages contain VHDL objects that may be shared by many design units
    • (Sub-)type declarations
    • Constants
    • Subprograms
    • Components
  • Package contents must be made available via use clauses
  • Implementation details can be hidden in a package body
  • Package body
    • Visible only within a package
    • Always linked to a package
    • May contain all declarations/definitions that are legal for a package
    • Holds definition of previously declared constants and subprograms

Notes

Packages are the only language mechanism to share objects among different design units.

Usually, they are designed to provide standard solutions for specific problems, e.g. data types and corresponding subprograms like type conversion functions for a certain bus protocol, procedures and components (macros) for signal processing purposes, etc.

A body is strictly needed if subprograms are to be placed in packages because only the declaration of functions and procedures may be placed in the package itself.

A package body is not needed if no subprograms or deferred constants are used.

Please note that only objects declared in a package can be referenced via use statements.

Package Syntax

Package declaration: Package body declaration: 
package IDENTIFIER is
-- declaration of
-- types and subtypes
-- subprograms
-- constants, signals and shared
-- variables
-- files
-- aliases
-- components
end [ package ] [ IDENTIFIER ];
 
package body IDENTIFIER is
-- definition of previously declared
-- constants
-- subprograms
-- declaration/definition of
-- additional types and subtypes
-- subprograms
-- constants, signals and shared
-- variables
-- files
-- aliases
-- components
end [ package body ] [ IDENTIFIER ];
Only the package content is visible, NOT the body
Subprogram definitions can not be placed in a package
VHDL’93: The keywords ’package’ / ’package body’ may be repeated after the keyword ’end’

Notes

The libraries WORK and STD and the STANDARD package are available by default.

Thus the corresponding VHDL statements are not needed. If a package body exists, it should be placed in a separate file. Otherwise it would not be possible to compile the separately.

Only the package content can be made visible with use statements so changes to constant declarations or subprogram bodies can be made in the package body without implying a recompilation of the complete design.

Only the package body has to be recompiled then.

Package Example

package PKG is
type T1 is ...
type T2 is ...
constant C : integer;
procedure P1 (...);
end PKG;
package body PKG is
type T3 is ...
 
C := 17;
procedure P1 (...) is
. . .
end P1;
procedure P2 (...) is
. . .
end P2;
end PKG;
library STD;           -- VHDL default
library WORK;          -- VHDL default
use STD.standard.all;  -- VHDL default
use work.PKG.all;
 
entity EXAMPLE is
end EXAMPLE;
 
architecture BEH of EXAMPLE is
signal S1 : T1;
signal S2 : T2;
signal S3 : T3; -- error: T3 not declared
Begin
 
P1 (...);
P2 (...); -- error: P2 not declared
end BEH;
  • Signals or procedures which are declared in the package body cannot be accessed
  • A specific new data type may be defined in only one of the referenced packages
  • Deferred constants: actual value assignment is package body

Notes

A package body is not necessary if no subprograms or deferred constants are declared.

In this example the type T3 and the procedure P2 are declared in the package body, only.

This leads to an error during compilation because these two items are not visible in the architecture.

Chapters of System Design > Project Management