VHDL entities, architectures and processes

prepared by P. Bakowski


A complete VHDL description needs to contain at least one module called entity. An entity  represents the interfaces of a model with the external environment possibly integrating more entities. The entities are inter-connected and communicate through signals. To each entity is associated one or more architectures. The architectures describe the internal behavior of the entity. This behavior  may be expressed in terms of  processes; each process describing independent sequential activities; or in terms of other entities considered as structural blocks. The architecture built only from processes and simple signal assignments is called behavioral architecture. The architectures composed from other entities referred to as components is called structural architecture.
In the following chapter we are going to present and to discuss the elements of entities and behavioral architectures.

Contents: entity declaration, architecture declaration, processes, sequential control, processes and assertions, processes and signal attributes, chaining delays in processes, concurrent procedures, exercises

VHDL entity declaration [syntax]

The basic descriptional element of VHDL is entity; each description must be composed from at least one entity.  Each entity has a set of ports which constitute its interface to the outside world. In VHDL, an entity may be the top level module of the design or  may be used as a component in a design.
entity horloge is
port(horl:out bit);
end horloge;
entity ones_counter is
port(a:in bit_vector(0 to 2); c:out bit_vector(0 to 1));
end ones_counter;
In general, the entity modules consist of two parts: The  header may include specification of generic constants. Generics allow to determine some quantitative aspects of the structure (e.g. size of the bus) and behavior (e.g. number of counting steps) of the entity.
entity ones_counter is
generic(retard: time:= 10 ns);
port(a:in bit_vector(0 to 2); c:out bit_vector(0 to 1));
end ones_counter;
The generics are actualized when the entity is instantiated as a component in a design.
The declarative part may be used to declare items (e.g. types, functions,..)  to be used in the implementation of the entity.  Optional statements in the entity declaration may be inserted to define some special behavior for monitoring operation of the entity (e.g.  checks on the input signals).

ports and signals

An entity port contains the  list of  items that must all be of class signal. Consequently, we are not required to write the keyword signal it is assumed by default.
port(signal a:in bit_vector(0 to 2); signal c:out bit_vector(0 to 1));
port(a:in bit_vector(0 to 2); c:out bit_vector(0 to 1));
-- both expressions are equivalent
The ports may specify the input (in), the output (out) and the input-output signals (inout).
port(reset:in bit;abus:out address; dbus:inout word);
The word buffer is a kind of inout signal.  It should be applied if the port is to be connected to an output -input signals used as a component in a design.
port(counter:buffer word);
A buffer port may have at most one signal assignment within the architecture.

elements of entity declaration

The declarative part of an entity may contain several kinds of items including:
  • type declarations
  • procedure or function definitions
  • assertions concerning the input signals
  • e.g. assert s'stable(10 ns)
    report "message"
    severity warning;
    An example:
    entity complex is
    -- entity header
    generic(retard: time:=10 ns)
    port(a: in bit; b: out bit_vector(n downto 0);
    -- entity declarative part
    type word is array(15 downto 0) of bit;
    procedure start(signal sig: word) is
    sig <= (others =>'1') after retard;
    end start;
    -- entity executable part
    assert a'delayed'stable(4 ns)
      report "erreur"
        severity error;
    end complex;

    VHDL architecture declaration [syntax]

    The architecture is a module used to define how entity behaves or what it is composed of. The architecture description may be abstract implying the use of abstract objects; RTL (register transfer level) oriented implying the use of hardware related object types like registers or buses or structural implying the use of smaller hardware modules referred to as components. Depending on the character of the design or description, the components may be embraced at block or core level or be may be much more detailed and imply the creation of logic level structures (logic netlists). Each architecture body can describe a different implementation of the entity.

    The potential composition of architecture module comprises:

    architecture declarative part

    The declarative part of the architecture may contain: Example:
    architecture exemple of entite_une is
    signal tmp:bit:=0;
    constant ret:time:=10 ns;
    function complement(mot:word) return word is
    -- local variables are not allowed
    for i in mot'range loop
    tmp(i) := not word(i);
    return tmp;
    end complement;
    component horl_comp
    port(horl:out bit)
    end component;
    -- architecture body starts here

    VHDL processes [syntax]

    Behavioral architecture descriptions use extensively the algorithmic programming of the circuit/system functionalities. The behavioral architectures are mainly built from processes. All operations described in a process are executed sequentially (procedurally). Processes are activated through the events on signals generated outside or within the process (VHDL'93 provides an attribute called 'driving which can indicate if the signal is driven from within a process). The processes active at the same time execute concurrently.

    basic process structure

    A process is built from two parts: the declaration part and the statements part
    label: process
    -- signals are not allowed
    end process label;
    The statements section of the process is the sequential program. The behavior of the process is a function of the signals read by the process. The results of behavior are applied to the signals which may activate other processes.

    wait statements

    A simple wait statement stops the execution of a process.
    A wait statement with signal list stops the execution of a process until one of the listed signals is activated.

    Any event on any signal listed frees the process.

    wait on signal_list;
    e.g. wait on a,b,cin;
    A wait statement with until condition stops the execution of a process until the condition becomes TRUE.
    wait until condition;
    e.g. wait until reset='1';
    A wait statement with for time_expression stops the process for the time specified by the expression.
    wait for time_expression;
    e.g. wait for 100 ns;
    A wait statement may combine several kinds of evaluations:
    wait on a,b until enable='1';
    t<= transport a and b;
    end process;
    RemarkThe process above (and_process) will reactivate whenever there is an event on a or b or enable but only if enable is equal to `1', otherwise the process remain suspended.

    sensitivity list versus wait statement

    The sensitivity list is a kind of wait operation specified in the header of process statement. In the table below we illustrate the alternative use of sensitivity list and wait statement.
    sensitivity list (..) wait statement
    output<= in1 or in2;
    end process;
    output<= in1 or in2; 
    wait on in1,in2;
    end process;
    Attention: The use of sensitivity list excludes the wait statements in the process

    Sequential control in process 

    The body of a VHDL process comprises one or more sequential statements and/or signal assignments. The conditional control of their execution depends on the evaluation of control statements and assertions. This in turn may involve the evaluation of signal attributes. Note that multiple signal assignments executed "sequentially" in a process follow the specific rules. These rules are explained in chaining delays in processes.

    Some examples of conditional control in processes:

    Multi-process architecture - an example

    The following model describes  latch architecture decomposed into three processes.

    Processes and assertion statements

    The assertions are efficient means to control process execution. For example specific input conditions may be checked before the execution of the related  statements. The general syntax of assertion is as follows. Remind that different severity levels yield different simulator response. When the condition is FALSE the message is sent to the system output; if no message is given "assertion violation" is reported.
    The following  is a well known model of RS flip-flop. The assertion is used to detect the forbidden state (s=1 and r=1) at the flip-flop inputs. Remark: Note that the same assertion may be specified in entity declaration. This makes constraints on the device independent from the internal architecture and visible at the interface level.

    Processes and signal related attributes

    As we have seen in the previous chapter concerning signals, VHDL provides a number of predefined signal related attributes. They allow to express different time related conditions and constraints.

    Some attributes which define signals themselves :

    Other are functions that provide the information about signals :

     'delayed attribute (signal):


    What is the resulting waveform of the output (s) signal?
    Another example:


    'stable attribute (function - boolean result)

    The `stable attribute is a boolean signal whose value is TRUE when an event has not occurred on the signal for the given time; otherwise is FALSE.
    Detection of spikes:

    'transaction attribute (signal- event result)

    The `transaction attribute is a bit signal which toggles every time when a transaction has occurred on the signal. Note that the `transaction attribute produces events even if the value of the signal has not changed.

    'active, 'event  attributes (function - boolean result)

    The `active attribute is a boolean signal which is TRUE when a transaction has occurred on the signal during the current simulation cycle. The `event attribute is a boolean signal which is TRUE when an event has occurred on the signal during the current simulation cycle.

    The following excl_process is sensitive to two input signals but its behavior depends on whether or not each of the inputs has changed.


    'last_active, 'last_event, 'last_value attributes (function - boolean result)

    The `last_active attribute returns the amount of time that has elapsed since there was a transaction on the signal. The `last_event attribute returns the amount of time that has elapsed since there was an event on the signal. The `last_value attribute returns the value of the signal before the last event.
    The first example shows how `last_value attribute  can be applied to detect the signal falling edge.  The second example presents the use of 'event and 'last_event attributes to test the setup time.  
     Setup time check:

    Chaining delays in processes

    Several consecutive signal assignments may produce different effects depending on the value of signal and type of delays used in the process. When inertial signal assignment is made, all driver values in the queue past the current time are deleted. This is not the case of transport delays which maintains the previously (in time) assigned values.

    More precise rule is given in the table below:

    inertial delay
    transport delay
    new transaction is scheduled
    before already existing
    overwrites existing transactions
    overwrites existing transactions
    new transaction is scheduled 
    after already existing
    overwrites existing transactions having different values,
    otherwise keeps the existing transactions
    appends the new transaction 
    to existing ones

    Concurrent procedures

    The VHDL architectures modules may contain concurrent procedure calls. A concurrent procedure is instantiated as a concurrent statement (e.g. signal assignment).  Concurrent procedure is equivalent to a process with a sensitivity list extracted from all the actual signals whose mode in the formal parameter list is of in or inout. All elements associated to the formal parameters during the procedure instantiation must be visible in the architecture. There can be multiple occurrences of a concurrent procedure with different formal=>actual parameters association lists. This allows the reuse of  the same procedure in different contexts.
    The concurrent procedure may be declared in a package, in the entity declarative part, or in the architecture declarative part. All classes of objects (signals, variables, constants and files) may be used as concurrent procedure parameters.

    adder_proc(a,b,cin: in std_logic; s,cout: out std_logic);
    -- a,b,cin,s,cout : are formal parameters