0 ..
VHDL - first example

prepared by P. Bakowski

Introduction

There are several ways to present the first example written in VHDL. Some readers having programming background would prefer to see a piece of program, others using graphical editors to design logic circuits would prefer to see a graphic module containing few interconnected  logic gates. Our choice is to illustrate both approaches by using  very simple and well known function of a one-bit full adder. This adder has a function and may be constructed from interconnected gates.

Some notational conventions:

The text is written with variable width policy; some important parts of the text are written with bold characters.
VHDL code is written with fixed width characters. The keywords are written with fixed width blue color characters. Some important elements in VHDL code may be signaled by using red color warning. Note that the types of objects are not treated as VHDL keywords.

Contents: describing structure, describing behavior, modeling time, first example, exercises

Describing Structure

A digital electronic system can be described as a module with inputs and/or outputs. The electrical values on the outputs are some function of the values on the inputs.
VHDL module called entity

The above module has tree inputs, a, b and cin , and two outputs s and cout. Using VHDL terminology, we call the module full adder a design entity , and the inputs and outputs are called ports .  One way of describing the function of a module is to describe how it is composed of sub-modules.  Each of the sub-modules is an instance of some entity, and the ports of the instances are connected using signals .

Hierarchically connected entities called components

Structural description of full adder might be composed of instances of entities M1, M2 and M3. This kind of description is called a structural description. Note that each of the entities M1, M2 and M3 might also have a structural description.

Describing behavior

In many cases, it is not appropriate to describe a module structurally. One such case is a module which is at the bottom of the hierarchy of some other structural description.  For example, if you are designing a system using IC packages bought from an IC shop, you do not need to model the internal structure of an IC. In such cases, only the description of the function performed (behavior) by the module is required, without reference to its actual internal structure.
Such a description is called a functional or behavioral. To illustrate this, suppose that the function of the entity full adder in the figure above could be the full adder functions:
s <= a xor b xor cin; -- behavior of s output : sum
cout <= (a and b) or (a and cin) or (b and cin); -- behavior of cout output : carry out
More complex behaviors cannot be described purely as a function of inputs. In systems with internal states, the outputs are also a function of these states and time. VHDL solves this problem by allowing description of behavior in the form of an event driven  simulation model.

Event driven model

Once the structure and behavior of a module have been specified, it is possible to simulate the module by executing its bevioural description. This is done by simulating the passage of time in discrete steps (events). At some simulation time, a module input may be stimulated by changing the value on an input port. The module reacts by running the code of its behavioral description and scheduling new values to be placed on the signals connected to its output ports at some later simulated time. This is called scheduling a transaction on that signal. If the new value is different from the previous value on the signal, an event occurs, and other modules with input ports connected to the signal may be activated.

The simulation starts with an initialization phase, and then proceeds by repeating a two- stage simulation cycle .
In the initialization phase, all signals are given initial values, the simulation time is set to zero, and each module's behavior program is executed. This usually results in transactions being scheduled on output signals for some later time. In the first stage of a simulation cycle, the simulated time is advanced to the earliest time at which a transaction has been scheduled. All transactions scheduled for that time are executed, and this may cause events to occur on some signals.
In the second stage, all modules which react to events occurring in the first stage have their behavior program executed. These programs will usually schedule further transactions on their output signals. When all of the behavior programs have finished executing, the simulation cycle repeats. If there are no more scheduled transactions, the whole simulation is completed.

The purpose of the simulation is to gather information about the changes in system state over time. This can be done by running the simulation under the control of a simulation monitor  (simulator) . The simulator maintains signals' states in corresponding  signal drivers. Future values of the signal are stored in a signal driver and activated when the simulation time arrives at their position on time axis (this time instant is called now).
Below we have illustrated the content of the driver of signal a. The current value of the signal a is '0' ; it will change to '1' in 10 ns;  this also means that the current value of b is '0'.
 

 
First example : combinational circuit
In this section we will look at a small example of a VHDL description of a one-bit full adder . To give you a feel for the language and how it is used, we start the description of an entity by specifying its external interface, which includes a description of its ports. The adder interface might be defined as:
-- single-bit adder
entity adder is
port (a,b,cin: in bit; sum,cout: out bit);
end adder;
The entity specifies an interface with 3 inputs and 2 outputs, all of which are bit values, that is, they can take on the only two values: `0' and `1'.  The following architecture is described functionally with two concurrent signal assignments  (<= denotes signal assignment).

Behavioral architecture of adder

-- description of adder using concurrent signal assignments
architecture flow of adder is
begin
sum <= (a xor b) xor cin; --  signal assignment
cout <= (a and b) or (cin and a) or (cin and b);
end flow;
This initial description may be developed in order to introduce some timing information through the generic statement. The generic statement permits to  predefine temporal parameters such as delays:
-- single-bit adder with delay parameters
entity adder is
generic(sum_del:TIME:=10 ns; carry_del: TIME:= 15 ns);
port (a,b,cin: in bit; sum,cout: out bit);
end adder;

Structural architecture of adder

The following architecture is built from several components - gates. The necessary components are prepared in a library called  bgates. bgates library contains the description of gates like xorg, andg, and org. These gates are considered as  components  are directly instantiated and interconnected through port map clause. Note that the same component may be instantiated several times using different instantiation names. In our example xor gate is instantiated twice as xor1 and as xor2).
Direct instantiation may be applied to components/entities with single architecture. The selection of  the components having more than one architecture requires the use of  configuration clause.
The following architecture uses a package called bgates and takes (potentially) all elements described in this package. The first part of the package contains the declarations of components (gates) defined later in the package. Note that these declarations have the same interfaces (inputs and outputs) as the gate entities defined later in the package body.
-- description of adder using direct instantiations of components
-- the corresponding entities are assumed to have only one architecture
use work.bgates.all;
architecture structural of adder is
signal xor1_out, and1_out, and2_out, or1_out : bit;
begin
xor1: xorg port map(in1 => a,in2 => b, out1 => xor1_out); -- instantiation of xor1 gate from xorg model
xor2: xorg generic map(2 ns; 2 ns) -- generic values instantiation: instantiated by default
port map(in1 => xor1_out, in2 => cin,out1 => sum); -- instantiation of xor2 gate from xorg model
and1: andg port map(in1 => a,in2 => b,out1 => and1_out);
or1: org port map(in1 => a,in2 => b,out1 => or1_out);
and2: andg port map( in1 => cin, in2 => or1_out, out1 => and2_out);
or2: org port map(in1 => and1_out,in2 => and2_out, out1 => cout);
end structural;

package bgates : a fragment containing the declaration and definition of xorg gate

-- package bgates with component declarations and entity definitions
package bgates is  -- package specification
..
component xorg
generic (tpd_hl : time := 1 ns; tpd_lh : time := 1 ns); -- default generic delays
port (in1, in2 : in bit; out1 : out bit);
end component;
end bgates;
-- gate entities
package body bgates is -- package body
..
entity xorg is
generic (tpd_hl : time := 1 ns; tpd_lh : time := 1 ns);
port (in1, in2 : in bit; out1 : out bit);
end xorg;
architecture only of xorg is
begin
p1: process(in1, in2)
variable val : bit;
begin
val := in1 xor in2;
case val is
when '0' => out1 <= '0' after tpd_hl;
when '1' => out1 <= '1' after tpd_lh;
when others => out1 <= val;
end case;
end process;
end only;
end bgates;  -- end of the package body

Waveform from the simulator


Exercises