This tutorial gives a brief overview of the VHDL language and is mainly intended as a companion for the Digital Design Laboratory. This writing aims to give the reader a quick introduction to VHDL and to give a complete or in-depth discussion of VHDL. For a more detailed treatment, please consult any of the many good books on this topic. Several of these books are listed in the reference list.

1. Introduction

VHDL stands for VHSIC (Very High Speed Integrated Circuits) Hardware Description Language. In the mid-1980’s the U.S. Department of Defense and the IEEE sponsored the development of this hardware description language with the goal to develop very high-speed integrated circuit. It has become now one of industry’s standard languages used to describe digital systems. The other widely used hardware description language is Verilog. Both are powerful languages that allow you to describe and simulate complex digital systems. A third HDL language is ABEL (Advanced Boolean Equation Language) which was specifically designed for Programmable Logic Devices (PLD). ABEL is less powerful than the other two languages and is less popular in industry. This tutorial deals with VHDL, as described by the IEEE standard 1076-1993.

Although these languages look similar as conventional programming languages, there are some important differences. A hardware description language is inherently parallel, i.e. commands, which correspond to logic gates, are executed (computed) in parallel, as soon as a new input arrives. A HDL program mimics the behavior of a physical, usually digital, system. It also allows incorporation of timing specifications (gate delays) as well as to describe a system as an interconnection of different components.

2. Levels of representation and abstraction

A digital system can be represented at different levels of abstraction [1]. This keeps the description and design of complex systems manageable. Figure 1 shows different levels of abstraction.

Figure 1: Levels of abstraction: Behavioral, Structural and Physical

The highest level of abstraction is the behavioral level that describes a system in terms of what it does (or how it behaves) rather than in terms of its components and interconnection between them. A behavioral description specifies the relationship between the input and output signals. This could be a Boolean expression or a more abstract description such as the Register Transfer or Algorithmic level. As an example, let us consider a simple circuit that warns car passengers when the door is open or the seatbelt is not used whenever the car key is inserted in the ignition lock At the behavioral level this could be expressed as,

Warning = Ignition_on AND ( Door_open OR Seatbelt_off)

The structural level, on the other hand, describes a system as a collection of gates and components that are interconnected to perform a desired function. A structural description could be compared to a schematic of interconnected logic gates. It is a representation that is usually closer to the physical realization of a system. For the example above, the structural representation is shown in Figure 2 below.

Figure 2: Structural representation of a “buzzer” circuit.

VHDL allows one to describe a digital system at the structural or the behavioral level. The behavioral level can be further divided into two kinds of styles: Data flow and Algorithmic. The dataflow representation describes how data moves through the system. This is typically done in terms of data flow between registers (Register Transfer level). The data flow model makes use of concurrent statements that are executed in parallel as soon as data arrives at the input. On the other hand, sequential statements are executed in the sequence that they are specified. VHDL allows both concurrent and sequential signal assignments that will determine the manner in which they are executed. Examples of both representations will be given later.

3. Basic Structure of a VHDL file

A digital system in VHDL consists of a design entity that can contain other entities that are then considered components of the top-level entity. Each entity is modeled by an entity declaration and an architecture body. One can consider the entity declaration as the interface to the outside world that defines the input and output signals, while the architecture body contains the description of the entity and is composed of interconnected entities, processes and components, all operating concurrently, as schematically shown in Figure 3 below. In a typical design there will be many such entities connected together to perform the desired function.

Figure 3: A VHDL entity consisting of an interface (entity declaration) and a body (architectural description).

VHDL uses reserved keywords that cannot be used as signal names or identifiers. Keywords and user-defined identifiers are case insensitive. Lines with comments start with two adjacent hyphens (--) and will be ignored by the compiler. VHDL also ignores line breaks and extra spaces. VHDL is a strongly typed language which implies that one has always to declare the type of every object that can have a value, such as signals, constants and variables.

a. Entity Declaration

The entity declaration defines the NAME of the entity and lists the input and output ports. The general form is as follows,

entity NAME_OF_ENTITY is [ generic generic_declarations);]

port (signal_names: mode type;

signal_names: mode type;

signal_names: mode type);

end [NAME_OF_ENTITY] ;

An entity always starts with the keyword entity, followed by its name and the keyword is. Next are the port declarations using the keyword port. An entity declaration always ends with the keyword end, optionally [] followed by the name of the entity.

· The NAME_OF_ENTITY is a user-selected identifier

· signal_names consists of a comma separated list of one or more user-selected identifiers that specify external interface signals.

· mode: is one of the reserved words to indicate the signal direction:

o in – indicates that the signal is an input

o out – indicates that the signal is an output of the entity whose value can only be read by other entities that use it.

o buffer – indicates that the signal is an output of the entity whose value can be read inside the entity’s architecture

o inout – the signal can be an input or an output.

· type: a built-in or user-defined signal type. Examples of types are bit, bit_vector, Boolean, character, std_logic, and std_ulogic.

o bit – can have the value 0 and 1

o bit_vector – is a vector of bit values (e.g. bit_vector (0 to 7)

o std_logic, std_ulogic, std_logic_vector, std_ulogic_vector: can have 9 values to indicate the value and strength of a signal. Std_ulogic and std_logic are preferred over the bit or bit_vector types.

o boolean – can have the value TRUE and FALSE

o integer – can have a range of integer values

o real – can have a range of real values

o character – any printing character

o time – to indicate time

· generic: generic declarations are optional and determine the local constants used for timing and sizing (e.g. bus widths) the entity. A generic can have a default value. The syntax for a generic follows,

generic (

constant_name: type [:=value] ;

constant_name: type [:=value] );

For the example of Figure 2 above, the entity declaration looks as follows.

-- comments: example of the buzzer circuit of fig. 2

entity BUZZER is

port (DOOR, IGNITION, SBELT: in std_logic;

WARNING: out std_logic);

end BUZZER;

The entity is called BUZZER and has three input ports, DOOR, IGNITION and SBELT and one output port, WARNING. Notice the use and placement of semicolons! The name BUZZER is an identifier. Inputs are denoted by the keyword in, and outputs by the keyword out. Since VHDL is a strongly typed language, each port has a defined type. In this case, we specified the std_logic type. This is the preferred type of digital signals. In contrast to the bit type that can only have the values ‘1’ and ‘0’, the std_logic and std_ulogic types can have nine values. This is important to describe a digital system accurately including the binary values 0 and 1, as well as the unknown value X, the uninitialized value U, “-” for don’t care, Z for high impedance, and several symbols to indicate the signal strength (e.g. L for weak 0, H for weak 1, W for weak unknown - see section on Enumerated Types). The std_logic type is defined in the std_logic_1164 package of the IEEE library. The type defines the set of values an object can have. This has the advantage that it helps with the creation of models and helps reduce errors. For instance, if one tries to assign an illegal value to an object, the compiler will flag the error.

A few other examples of entity declarations follow

Four-to-one multiplexer of which each input is an 8-bit word.

entity mux4_to_1 is

port (I0,I1,I2,I3: in std_logic_vector(7 downto 0);

     SEL: in std_logic_vector (1 downto 0);

OUT1: out std_logic_vector(7 downto 0));

end mux4_to_1;

An example of the entity declaration of a D flip-flop with set and reset inputs is

entity dff_sr is

port (D,CLK,S,R: in std_logic;

Q,Qnot: out std_logic);

end dff_sr;

b. Architecture body

The architecture body specifies how the circuit operates and how it is implemented. As discussed earlier, an entity or circuit can be specified in a variety of ways, such as behavioral, structural (interconnected components), or a combination of the above.

The architecture body looks as follows,

architecture architecture_name of NAME_OF_ENTITY is

-- Declarations

-- components declarations

-- signal declarations

-- constant declarations

-- function declarations

-- procedure declarations

-- type declarations

begin

-- Statements

end architecture_name;

Behavioral model

The architecture body for the example of Figure 2, described at the behavioral level, is given below,

architecture behavioral of BUZZER is

begin

WARNING <= (not DOOR and IGNITION) or (not SBELT and IGNITION);

end behavioral;

The header line of the architecture body defines the architecture name, e.g. behavioral, and associates it with the entity, BUZZER. The architecture name can be any legal identifier. The main body of the architecture starts with the keyword begin and gives the Boolean expression of the function. We will see later that a behavioral model can be described in several other ways. The “<= ” symbol represents an assignment operator and assigns the value of the expression on the right to the signal on the left. The architecture body ends with an end keyword followed by the architecture name.

A few other examples follow. The behavioral description of a two-input AND gate is shown below.

entity AND2 is

port (in1, in2: in std_logic;

out1: out std_logic);

end AND2;

architecture behavioral_2 of AND2 is

begin

out1 <= in1 and in2;

end behavioral_2;

An example of a two-input XNOR gate is shown below.

entity XNOR2 is

port (A, B: in std_logic;

Z: out std_logic);

end XNOR2;

architecture behavioral_xnor of XNOR2 is

-- signal declaration (of internal signals X, Y)

signal X, Y: std_logic;

begin

X <= A and B;

Y <= (not A) and (not B);

Z <= X or Y;

End behavioral_xnor;

The statements in the body of the architecture make use of logic operators. Logic operators that are allowed are: and, or, nand, nor, xor, xnor and not. In addition, other types of operators including relational, shift, arithmetic are allowed as well (see section on Operators). For more information on behavioral modeling see section on Behavioral Modeling.

Concurrency

It is worth pointing out that the signal assignments in the above examples are concurrent statements. This implies that the statements are executed when one or more of the signals on the right hand side change their value (i.e. an event occurs on one of the signals). For instance, when the input A changes, the internal signals X and Y change values that in turn causes the last statement to update the output Z. There may be a propagation delay associated with this change. Digital systems are basically data-driven and an event which occurs on one signal will lead to an event on another signal, etc. The execution of the statements is determined by the flow of signal values. As a result, the order in which these statements are given does not matter (i.e., moving the statement for the output Z ahead of that for X and Y does not change the outcome). This is in contrast to conventional, software programs that execute the statements in a sequential or procedural manner.

Structural description

The circuit of Figure 2 can also be described using a structural model that specifies what gates are used and how they are interconnected. The following example illustrates it.

architecture structural of BUZZER is

-- Declarations

component AND2

port (in1, in2: in std_logic;

out1: out std_logic);

end component;

component OR2

port (in1, in2: in std_logic;

out1: out std_logic);

end component;

component NOT1

port (in1: in std_logic;

out1: out std_logic);

end component;

-- declaration of signals used to interconnect gates

signal DOOR_NOT, SBELT_NOT, B1, B2: std_logic;

begin

-- Component instantiations statements

U0: NOT1 port map (DOOR, DOOR_NOT);

U1: NOT1 port map (SBELT, SBELT_NOT);

U2: AND2 port map (IGNITION, DOOR_NOT, B1);

U3: AND2 port map (IGNITION, SBELT_NOT, B2);

U4: OR2 port map (B1, B2, WARNING);

end structural;

Following the header is the declarative part that gives the components (gates) that are going to be used in the description of the circuits. In our example, we use a two- input AND gate, two-input OR gate and an inverter. These gates have to be defined first, i.e. they will need an entity declaration and architecture body (as shown in the previous example). These can be stored in one of the packages one refers to in the header of the file (see Library and Packages below). The declarations for the components give the inputs (e.g. in1, in2) and the output (e.g. out1). Next, one has to define internal nets (signal names). In our example these signals are called DOOR_NOT, SBELT_NOT, B1, B2 (see Figure 2). Notice that one always has to declare the type of the signal.

The statements after the begin keyword gives the instantiations of the components and describes how these are interconnected. A component instantiation statement creates a new level of hierarchy. Each line starts with an instance name (e.g. U0) followed by a colon and a component name and the keyword port map. This keyword defines how the components are connected. In the example above, this is done through positional association: DOOR corresponds to the input, in1 of the NOT1 gate and DOOR_NOT to the output. Similarly, for the AND2 gate where the first two signals (IGNITION and DOOR_NOT) correspond to the inputs in1 and in2, respectively, and the signal B1 to the output out1. An alternative way is to use explicit association between the ports, as shown below.

label: component-name port map (port1=>signal1, port2=> signal2,… port3=>signaln);

U0: NOT1 port map (in1 => DOOR, out1 => DOOR_NOT);

U1: NOT1 port map (in1 => SBELT, out1 => SBELT_NOT);

U2: AND2 port map (in1 => IGNITION, in2 => DOOR_NOT, out1 => B1);

U3: AND2 port map (in1 => IGNITION, in2 => SBELT_NOT, B2);

U4: OR2 port map (in1 => B1, in2 => B2, out1 => WARNING);

Notice that the order in which these statements are written has no bearing on the execution since these statements are concurrent and therefore executed in parallel. Indeed, the schematic that is described by these statements is the same independent of the order of the statements.

Structural modeling of design lends itself to hierarchical design, in which one can define components of units that are used over and over again. Once these components are defined they can be used as blocks, cells or macros in a higher level entity. This can significantly reduce the complexity of large designs. Hierarchical design approaches are always preferred over flat designs. We will illustrate the use of a hierarchical design approach for a 4-bit adder, shown in Figure 4 below. Each full adder can be described by the Boolean expressions for the sum and carry out signals,

sum = (A Å B) Å C

carry = AB + C(A Å B)

Figure 4: Schematic of a 4-bit adder consisting of full adder modules.

In the VHDL file, we have defined a component for the full adder first. We used several instantiations of the full adder to build the structure of the 4-bit adder. We have included the library and use clause as well as the entity declarations.

Four Bit Adder – Illustrating a hierarchical VHDL model

-- Example of a four bit adder

library ieee;

use ieee.std_logic_1164.all;

-- definition of a full adder

entity FULLADDER is

port (a, b, c: in std_logic;

sum, carry: out std_logic);

end FULLADDER;

architecture fulladder_behav of FULLADDER is

begin

sum <= (a xor b) xor c ;

carry <= (a and b) or (c and (a xor b));

end fulladder_behav;

-- 4-bit adder

library ieee;

use ieee.std_logic_1164.all;

entity FOURBITADD is

port (a, b: in std_logic_vector(3 downto 0);

Cin : in std_logic;

sum: out std_logic_vector (3 downto 0);

Cout, V: out std_logic);

end FOURBITADD;

architecture fouradder_structure of FOURBITADD is

signal c: std_logic_vector (4 downto 0);

component FULLADDER

port(a, b, c: in std_logic;

sum, carry: out std_logic);

end component;

begin

FA0: FULLADDER