VHDL Basics Madhav P. Desai Tel: x7423 Office hours: Wednesday - - PDF document

VHDL Basics

Madhav P. Desai Tel: x7423 Office hours: Wednesday 4pm-5pm email: madhav@ee.iitb.ac.in August 20, 2009

What should an ideal HDL look like? Well, it should certainly be able to model hardware (let us stick to logic circuits for now!). But do we always have to think of logic circuits as networks of simple logic gates? I mean, sometimes I want to think of an adder as something that adds, rather than a network

• f Nand gates, right? So an ideal HDL should be able to model hardware at

various levels of abstraction. Now, the whole purpose of an HDL is to be able to describe a system so that I can simulate it (and potentially convert the description into an implementation). So, there must be a well defined algorithm by which this simulation can be carried out. A particular HDL description must be simulatable by a well defined and efficient algorithm. It is an added benefit if the algorithm is deterministic

• r unambiguous, that is, if it produces the same results whenever it is applied.

Next, an HDL should certainly be compact and follow the write-once-use- many-times principle, so that I can re-use descriptions that I have already writ- ten to the maximum extent possible. In effect, I should be able to describe a complex system as compactly as possible, and the language should allow me to eliminate redundancies in the description to the maximum extent. Clearly, an HDL must be usable in an industry sense. It should be possible for large groups of people to collaborate in the description of a system. This is especially important in commercial collaborations, where partners may wish to share only a part of the description to protect their intellectual property. And it should certainly be able to model software, because most systems that we use today have a hardware aspect and a software aspect! Defining such an ideal HDL is certainly a daunting task, but VHDL comes close: it goes a long way towards meeting all the requirements of an ideal HDL except for the last one. And for this reason, VHDL is an interesting language to study, and a powerful language for hardware design.

1 The VHDL view of Hardware

The VHDL view of the system being described is actually quite simple. The system is considered to have a boundary and an interior. The boundary of the 1

system defines ports through which the system interacts with the environment. The interior of the system is viewed as a network of drivers and signals. A signal is analogous to an electrical wire which carries a value. Ports at the boundary

• f the system can be viewed as special signals. A change in value of a signal

is termed an event. Drivers react to events on signals and produce events on

• signals. The reaction of a driver to an event on a signal to which it is connected

is termed its behaviour. The power of VHDL comes from the mechanisms it provides to describe such a network. In a nutshell, these mechanisms can be summarized as follows:

• A flexible mechanism to define a type for signal values.
• A natural way to express hierarchy: the interior of a system can be con-

structed by instantiating other systems.

• A powerful mechanism to define complex behaviour of drivers: in particu-

lar, a system may be described as a small network of very complex drivers (in the limit, with a single driver) or a large network of very simple drivers (where each driver represents a simple logic gate).

• Subprograms for compact representations of complex systems.
• A flexible way to define and use parameters.
• Mechanisms for compact representations of array structures.
• A configuration mechanism to modify parts of the system without exten-

sive changes to existing code.

• An unambiguous simulation algorithm without race conditions1.

Thus, VHDL is in many ways a complete hardware description language: it exhibits most of the qualities that an HDL should have.

2 An example

Consider the following description of a simple two input XOR gate. package MyPack is type mybit is (’0’,’1’); -- type definition. end package MyPack; library work;

• - a collection of design units..

use package work.MyPack.all; -- use all definitions from MyPack. entity Xor2 is port(a,b: in mybit; c: out mybit);

1Unfortunately, the latest VHDL standard includes a notion of shared variables which

destroys this property.

2

end entity Xor2; architecture Behave of Xor2 is signal abbar, abarb: mybit; begin

• - Driver 1

abbar <= ’1’ when (a = ’1’ and b = ’0’) else ’0’;

• - Driver 2

abarb <= ’1’ when (a = ’0’ and b = ’1’) else ’0’;

• - Driver 3

c <= ’1’ when (abbar = ’1’ or abarb = ’1’) else ’0’; end architecture Behave; In this description, there is a definition of a type mybit which defines a set

• f possible values {′0′,′ 1′}. The ports of entity Xor2 have type mybit, and

so do the signals describing the network of drivers in the architecture Behave

• f Xor2. The architecture Behave itself describes a network consisting of three
• drivers. Each driver is an example of a concurrent signal assignment in VHDL.

The behaviour of each driver is as follows. The driver responds to events

• n signals on which it depends. For example, Driver 1 depends on signals a, b.

Whenever an event occurs on either a or b, the right hand side of the driver is

• evaluated. If the value computed is different from the value currently held by

signal abbar, then an event is generated on abbar2. This event on abbar will in turn excite Driver 3 which potentially creates events on the output port c of Xor2. Note that the drivers are concurrent. That is, a driver evaluates exactly when there is some event on a signal on which it depends, and there is no implied order in the execution of the drivers (that is, the order in which the drivers are written is irrelevant)! Some more points about this example:

• 1. A VHDL description is a collection of libraries, each of which is a collection
• f design units (See Figure 1). In this example, there are three such units,

a package named MyPack, an entity named Xor2, and an architecture of entity Xor2 named Behave.

• 2. The design units are organized into libraries. In this case, all design units

are in the default library, which is named “work”.

• 3. Type and Signal declarations are made inside the declarative regions of

design units. For instance, an entire package is a declarative region, and the region between the “is” and “begin” keywords in the architecture design unit is a declarative region.

2The simulation algorithm for a VHDL description will be described in the next class

3

VHDL Description library work library

• ther libraries

std Design units − Package Standard Design Units (user defined) − packages − entities − architectures

• thers...

Figure 1: Wire network

• 4. The entity design unit Xor2 defines the ports of the system Xor2. Ports

have directions (in this example, two directions are used, in and out).

• 5. The architecture Behave of Xor2 consists of a set of concurrent signal

assignments (the order in which the assignments are listed is irrelevant). Each concurrent signal assignment defines a driver. In subsequent lectures, we will cover the different design units possible in VHDL, type and objects (such as signals), processes, generate statements, sub- programs and configurations. More importantly, we will study how these build- ing blocks can be used to describe complex systems in a compact manner, and how these descriptions can be verified using simulation.

3 Reading assignment

Read the first chapter of Perry’s book. 4