courses:system_design:vhdl_language_and_syntax:vhdl_structural_elements:entity_and_architecture

Entity and Architecture

Entity

Entity 

entity HALFADDER is
  port(A, B       : in bit;
       SUM, CARRY : out bit);
end HALFADDER;
-- VHDL’93: end entity HALFADDER;
VHDL’93: The keyword ‘entity’ may be repeated after the keyword ‘end’ 
entity ADDER is
  port(A, B: in integer range 0 to 3;
       SUM : out integer range 0 to 3;
       CARRY: out bit);
end ADDER;
  • Interface description
  • No behavioral definition
  • Linking via port signals
    • Data types
    • Signal width
    • Signal direction

Notes

On the following pages, a fulladder consisting of two halfadders and an OR gate will be created step by step. We confine ourselves to a purely structural design, i.e. we are using gate level descriptions and do not need any synthesis tools. The idea is to demonstrate the interaction of the different VHDL objects in a straightforward manner.

The interface between a module and its environment is described within the entity declaration which is initiated by the keyword ’entity’. It is followed by a user-defined, (hopefully) descriptive name, in this case: HALFADDER. The interface description is placed between the keyword ’is’ and the termination of the entity statement which consists of the keyword ’end’ and the name of the entity. In the new VHDL’93 standard the keyword ’entity’ may be repeated after the keyword ’end’ for consistency reasons.

The input and output signal names and their data types are defined in the port statement which is initiated by the keyword ’port’. The list of ports is enclosed in a ’(’ ’)’ pair. For each list element the port name(s) is given first, followed by a ’:’, the port mode and the data type. Within the list, the ’;’ symbol is used to separate elements, not to terminate a statement. Consequently, the last list element is not followed by a ’;’!

Several ports with the same mode and data type can be declared by a single port statement when the port names are separated by ’,’. The port mode defines the data flow (in: input, i.e. the signal influences the module behavior; out: output, i.e. the signal value is generated by the module) while the data type determines the value range for the signals during simulation.

Architecture

Architecture 

entity HALFADDER is
   port(A,B        : in bit;
        SUM, CARRY : out bit);
end HALFADDER;
architecture RTL of HALFADDER is
begin
   SUM   <= A xor B;
   CARRY <= A and B;
end RTL;
-- VHDL’93: end architecture RTL;
VHDL’93: The keyword ‘architecture’ may be repeated after the keyword ‘end’
  • Implementation of the design
  • Always connected with a specific entity
    • One entity can have several architectures
    • Entity ports are available as signals within the architecture
  • Contains concurrent statements

Notes

The architecture contains the implementation for an entity which may be either a behavioral description (behavioral level or, if synthesizable, RT level) or a structural netlist or a mixture of those alternatives.

An architecture is strictly linked to a certain entity. An entity, however, may very well have several architectures underneath, e.g. different implementations of the same algorithm or different abstraction levels. Architectures of the same entity have to be named differently in order to be distinguishable. The name is placed after the keyword ’architecture’ which initiates an architecture statement. ’RTL’ was chosen in this case.

It is followed by the keyword ’of’ and the name of entity that is used as interface (’HALFADDER’). The architecture header is terminated by the keyword ’is’, like in entity statements. In this case, however, the keyword ’begin’ must be placed somewhere before the statement is terminated. This is done the same way as in entity statements: The keyword ’end’, followed by the architecture name. Once again, the keyword ’architecture’ may be repeated after the keyword ’end’ in VHDL’93.

As the VHDL code is synthesizable, RTL was chosen as architecture name. In case of this simple function, however, there is no difference to behavioral (algorithmic) description. We will use ’BEHAVE’, ’RTL’, ’GATE’, ’STRUCT’ and ’TEST’ to indicate the abstraction level and the implemented behavior, respectively. The name ’EXAMPLE’ will be used whenever the architecture shows the application of new VHDL elements and is not associated with a specific entity.

Architecture Structure

architecture EXAMPLE of STRUCTURE is
 
  subtype  DIGIT is integer range 0 to 9;
  constant BASE : integer := 10;
  signal   DIGIT_A, DIGIT_B : DIGIT;
  signal   CARRY            : DIGIT;
 
begin
 
  DIGIT_A <= 3;
 
  SUM <= DIGIT_A + DIGIT_B;
 
  DIGIT_B <= 7;
 
  CARRY <= 0 when SUM < BASE else
           1;
 
end EXAMPLE;
  • Declarative part:
    • Data types
    • Constants
    • Additional signals (“actual” signals)
    • Components
    • …
  • Definition part (after ‘begin’):
    • Signal assignments
    • Processes
    • Component instantiations
    • Concurrent statements: order not important

Notes

Each architecture is split into an optional declarative part and the definition part.

The declarative part is located between the keywords ’is’ and ’begin’. New objects that are needed only within the architecture constants, data types, signals, subprograms, etc. can be declared here.

The definition part is initiated by the keyword ’begin’ and holds concurrent statements. These can be simple signal assignments, process statements, which group together sequential statements, and component instantiations. Concurrency means that the order in which they appear in the VHDL code is not important. The signal SUM, for example, gets always the result of (3 + 7), independently of the location of the two assignments to the signals DIGIT_A and DIGIT_B.

Signal assignments are carried out by the signal assignment operator ’⇐’. The symbol represents the data flow, i.e. the target signal whose value shall be updated is placed on the left side of the operator. The right side holds an expression that evaluates to the new signal value. The data types on the left and on the right side have to be identical. Please remember that the signals that are used in this example were defined implicitly by the port declaration of the entity.

Entity Port Modes

Architecture with In- and Outports

  • in:
    • signal values are read-only
  • out:
    • signal values are write-only
    • multiple drivers

Architecture with buffer port

  • buffer:
    • comparable to out
    • signal values may be read, as well
    • only 1 driver

Architecture with Inout port

  • inout:
    • bidirectional port
Output port modes have to match

Notes

The mode of an entity port restricts the direction of the data flow. The port mode ’in’ is used to classify those signals that are only read in the underlying architecture. It is not possible to update their values.

Likewise, the port mode ’out’ denotes signals whose values are generated by the architecture. Their values can not be used to influence the behavior in any form. If the current output value has to be used to calculate the next signal value, e.g. within a counter module, an intermediate signal must be declared. Internal signals do not have a data flow direction associated with them!

Alternatively it is possible to use the port mode ’buffer’. This eliminates the need for an additional signal declaration. However, there is just a single source allowed for these signals.

In order to model busses, where multiple units have access to the same data lines, either the port mode ’out’ has to be used, if each unit is only writing to this data bus, or the port mode ’inout’ which allows a bidirectional data flow.

Please note that the port modes have to match, if the output port of a submodule is connected directly to the output port of the entity on a higher hierarchy level. At the worst, intermediate signals have to be declared to avoid compilation errors.

Chapters of System Design > VHDL Language and Syntax > VHDL Structural Elements

Chapters of System Design > VHDL Language and Syntax