CHAPTER 1

Introduction and Background

1.1 VHDL

VHDL. Four little letters. So much to understand.

There are many approaches to learning the Very-High-Speed Integrated Circuit Hardware

Description Language (VHDL). These range from the academic – where each piece is looked

at, turned upside down and inside out, and fully understood at an atomic level, yet only a few

understand how to actually USE the language to implement a design; to OJT1 where an

engineer may be handed either poorly written code (or in rare cases a well written piece of

code), or nothing at all and told that they are now responsible for the Field Programmable Gate

Array (FPGA) in the system.

Somewhere in between lays a happy medium – a way to learn VHDL and be productive as

quickly as possible.

I have a strong background in the Japanese Martial Art of Aikido. Like so many Martial Arts

there are ‘‘beginning techniques’’, ‘‘intermediate techniques’’, and ‘‘advanced techniques’’, yet

all of them are built on certain fundamental ideas of movement. It would be a disservice to

a student to spend hundreds of hours on wrist techniques alone without covering falling

techniques (one way to avoid harm), or posture, or any number of other important aspects of

the Art.

We start out simply, get a rough idea of what we’re in for – sort of a sampling of the various

aspects, but none in any great detail.

Now that the student has an idea of what he’s in for, he2 has a better idea of what lies ahead so

that the next iteration of falling, arm techniques, wrist techniques, knee work, etc., there is

a context in which to place the learning. In this fashion, an upward spiral of success is

achieved.

1 On-The-Job-Training, most often this is a ‘‘sink-or-swim’’ scenario. Without a framework, engineers who learnin this style often code inefficiently.

2 I use ‘‘he’’ instead of the awkward ‘‘he/she’’ or the more encompassing ‘‘he/she/he–she/she–he/it’’. This is notout of sexism, but out of long tradition, in virtually every language, of using the third person masculine for whenthe gender of the reader is unknown (as opposed to indeterminate).

VHDL 101.

Copyright ª 2011 Elsevier Inc. All rights reserved. 1

I’d like to take you on this same path in VHDL. We’ll start out by traversing the general

process of developing an FPGA.3 During this process you will encounter ‘‘forward

references’’, that is, references to aspects of VHDL that we haven’t covered yet. Currently,

there is no known way to avoid this problem except through a highly academic, ‘‘atomic’’ view

of the language, with no references or context relative to other aspects or commands of

the language. This is exactly what we are attempting to AVOID. When you see a new

construct, there will be a brief conceptual description of what it does and the details will be

provided later.

Once we’ve made our first ‘‘loop’’ through the material, we’ll revisit the initial concepts and

statement and begin adding to it and exploring the capabilities of the language. We’ll also

begin looking at some of the synthesis tool’s capabilities and how to verify that the code is

behaving properly prior to testing it in silicon (i.e. simulation).

The focus of this book is on VHDL which is one of the primary FPGA languages, but who

wants to work in a vacuum? References to various tools and other languages are made to

help the reader better understand the landscape into which he is entering. The Xilinx tools will

only be covered to the extent that they are required to produce a viable netlist and for

simulation. Other books, websites and classes from the FPGA vendors delve into great detail

as to how the various tools can be effectively applied.

This book is, by no means, the end-all, be-all reference for VHDL. The intention is to convey

the basic principles of VHDL with a smattering of FPGA techniques so that the VHDL

has relevance and so that you can get started coding quickly. In that vein neither every aspect

of VHDL is covered, nor are the covered aspects detailed to the nth degree – but they are

covered enough to get you coding for FPGAs very quickly.

There are a number of very good, extremely detailed books out there – look for anything

written by Peter Ashenden.

1.2 Brief History of VHDL

Way back, in the BEFORE TIME, say around 1981, the US Department of Defense began

writing the specifications for the Very-High-Speed Integrated Circuit (VHSIC) program. The

intent was to be able to accurately and thoroughly describe the behavior of circuits for

documentation, simulation, and (later) synthesis purposes. This initiative was known as

VHDL. July of 1983 saw Intermetics, IBM, and Texas Instruments begin developing the first

version of VHDL, which was finally released in August of 1985.

3 Although the focus of this book is VHDL, I believe that a brief overview of the entire flow helps create a contextin which to place this learning.

2 Chapter 1

Just to flesh out the timeline, Xilinx invented the first FPGA in 1984, began shipping parts in

1985, and was supporting VHDL shortly thereafter using a third-party synthesis tool.

Due to the popularity of the language, the Institute of Electrical and Electronics Engineers

(IEEE) convened a committee to formalize the language. This task was completed in 1987 and

the standard became known as IEEE 1076-1987. This standard has been revisited a number

of times (1993 and 2000) since then, and the current standard IEEE 1076-2008 is known

informally as VHDL-2008. As this latest standard has not yet been ratified (at the time of

writing), we will use the IEEE 1076-2000 standard which tends to be a superset of previous

versions.

VHDL is a large, complex, and powerful language. Although the language is feature-rich,

many designs only require a small subset of the total capabilities.

As a Department of Defense (DoD) project where, quite literally, lives were at stake, no aspect

of VHDL would be assumed and it was deigned to be a ‘‘strongly typed’’ language, sharing

many concepts and features with the programming language Ada.

VHDL gained very rapid acceptance (as it was mandated by DoD of their agencies

and contractors), initially on the East Coast. This is in contrast to Verilog, another FPGA

‘‘programming’’ language, which began its life as a programming language for Application

Specific Integrated Circuits (ASICs) and is particularly strong on the West Coast.

VHDL’s history still weighs on the current implementation, most notably in the ‘‘process

sensitivity list’’ used for simulation. At the time that VHDL was developed, the then

‘‘brand new’’ PC class machines were running at 5 MHz and 640 KB of memory. Processor

cycles were very expensive! So, in order not to waste processor time, the process

sensitivity list was examined to see if key signals had changed since the last iteration. If so, the

block of code was executed, otherwise it was skipped. This is one of the places where

some problems of today can occur as the synthesis tools ignore the process sensitivity list and

we encounter an error known as ‘‘simulation mismatch’’.

1.2.1 Coding Styles: Structural vs. Behavioral vs. RTL

You may hear several adjectives used with VHDL – Structural VHDL, Behavioral VHDL,

RTL coding, etc. These are not separate languages, but rather different approaches to coding.

These methods are not mutually exclusive, but may be mixed freely within a project or even a

single module.

Structural VHDL or structural coding is a very low-level style of coding. This practice involves

instantiating, or calling out explicitly, specific instances of primitives or previously defined

modules and wiring them together. Although an entire system can be developed this way, in

practice this is rare as this method is extremely time-consuming. There are three places where

Introduction and Background 3

this style is typically used – at the top level of a design where large lower-level modules are

stitched together, when a specialized piece of Intellectual Property (IP) is provided often as a

‘‘black box’’4, or when specific architectural features such as block memory, high-performance

communication cores, or other specialized silicon resources, are required.

RTL stands for Register Transfer Level and refers to a coding style that defines how signals

flow between hardware registers and the logical operations that occur between the registers.

This is one step more abstracted than structural coding as the independent logic elements

don’t need to be instantiated but can rather be inferred5 from equations.

The next level more abstracted is called ‘‘Behavioral Coding’’. This adds an additional layer of

abstraction in that software-type constructs such as ‘‘for loops’’, ‘‘if statements’’, and ‘‘case

statements’’. There is a common misunderstanding that ‘‘Behavioral Coding’’ can only be tied

to simulation – this is most certainly not the case! While it is true that some Behavioral Coding

constructs cannot be synthesized, many can be. This term is most often confused with

‘‘Behavioral Modeling’’ which is reserved for simulation.

Since simulation test benches run only on the development platform and aren’t required to

generate hardware they may contain constructs which cannot be translated into a hardware

structure. One may accurately consider VHDL in the simulation domain, a superset of

capabilities over VHDL for synthesis (conversion into hardware). Whether you choose to

code in the Behavioral, RTL, or Structural style has nothing to do (other than the use of

non-synthesizable constructs) with whether code is strictly synthesizable or not.

1.3 FPGA Architecture

Coding effectively, regardless of the language you select, requires some basic understanding

of the device’s architecture, so we’ll take this opportunity to have a very brief overview of the

main aspects of a generic FPGA’s innards (see Figure 1.16).

Notice the columnar organization of this device – Xilinx calls this ‘‘ASMBL’’ for Advanced

Silicon Modular Block. This enables Xilinx to rapidly (and reliably) construct multiple

variations within a family by adding additional columns and/or blocks of rows to create a

device to meet customer demands.

4 Ablackbox, in this context, is a piece of code, usually providedas a netlist. Thevendorwill provide a description of thesignals entering and exiting the module which is all the information required to instantiate this black box.

5 Inference indicates that the synthesis tools make certain decisions based on user settings as to how toconvert the described function into FPGA primitives. The user may provide an abstract concept, such asaddition, and the synthesis tools will decide how many multiplexers, LUTs (combinatorial logic generator), orother primitive resources are required to implement the specified equation.

6 This overview does not represent any specific FPGA, rather a composite of many of the features typically foundin a modern FPGA.

4 Chapter 1

The columns on the leftmost, rightmost, and center represent I/O resources. An I/O resource

may consist of any mix of input and output buffers (many support both single ended and

differential), registers for supporting Double Data Rate (DDR), programmable termination

resistors, programmable delay elements, and serializer/deserializer modules. These I/O blocks

effectively connect the package pins to specific signals internal to the FPGA.

The short dark region in the center column represents some of the clocking resources. These

resources include devices for multiplying up (or down) the incoming clock signals using

Digital Clock Managers (DCMs) and/or analog Phase Locked Loops (PLLs). There are also

a number of specialized differential clock distribution buffers located in this area.

Other resources such as blocks of memory, multipliers, Digital Signal Processing (DSP)

blocks, microprocessors, high-speed serial I/O, PCIe, and other specialized devices may be

found in the other columns.

As a general rule of thumb: if you want your design to run as fast as possible with the least

impact on power and area, use the dedicated silicon resources wherever possible. If, on

the other hand, you must make your code portable to other FPGAs which may lack these

resources, you should target the fabric.

Further discussion of these specific silicon resources is out of the scope of this book. Contact

your FPGA manufacturer for appropriate User Guides and courses.

The small blocks interspersed among the columns are, in the Xilinx lexicon, referred to as

Configurable Logic Blocks (CLBs). These blocks support both combinatorial logic processes

as well as registers. These CLBs are comprised of more granular modules called ‘‘Slices’’.

Depending on the family, there may be two or more Slices per CLB, and each Slice may

contain two or more pairs of Look-Up Tables (LUTs) and registers. In addition to the LUTand

register, there are multiplexers that are used for combining and directing where the signals go.

Generally, this is where the bulk of a design winds up (see Figure 1.2).

Figure 1.1: Coarse Look at a Generic FPGA Architecture.6

Introduction and Background 5

These logic and register resources are referred to as the FPGA ‘‘fabric’’ to differentiate it from

dedicated silicon resources.

The last major resource, which is not shown in the illustration for purposes of clarity, is the

routing which, although surprising at first, accounts for the majority of the silicon area in the

device. According to the June 2006 issue of the IEEE Spectrum, a typical FPGA contains

many kilometers of routing!

You will see numerous references to a ‘‘silicon resource’’. For clarity, this is any single or

collective entity within the FPGAwhether it is a humble Look-Up Table or LUT (found within

a CLB) or a PCIe core or processor.

All of the interconnects, FPGA fabric, and dedicated silicon resources are connected via

a series of run-time static switches which regulate the flow and connection of

information through the system. It is these switches and connections as well as the

‘‘equations’’ programmed into the LUTs that must be focused upon when the code is

written.

With that, let’s begin with a brief introduction to the overall flow of developing an FPGA and

where VHDL fits in this process.

Figure 1.2: Generic ‘‘Slice’’.

6 Chapter 1

1.3.1 Creating the Design

Volumes have been written on how to successfully execute a design. Since this is a book on

VHDL and not on design philosophies, we will not delve too deeply into this topic.

Suffice it to say that design philosophies range from the incredibly detailed ‘‘think everything

out in painful detail from every angle before you lift a finger to writing a single line of code’’

(which, by the way, is an excellent way to go for larger designs), to completely ad hoc ‘‘sit

down and start coding and resolve issues along the way’’ which only works effectively for

small designs.

Organizing the design and resolving issues before coding iswhere the real designing takes place.

Using detail oriented processes, such as those outlined by the IEEE for software development,

may be a bit tedious and cumbersome, but results in a higher quality of codewhich requires little

debugging time and, although there isn’t much apparent forward progress when writing the

design description, it will greatly accelerate the project once the coding has begun.

Many designers choose a point somewhere between these two extremes which consist

of a system-level block diagram and some research on specific algorithms to be

implemented.

All this said, good design practices are important for a successful FPGA design, so hints,

coding examples, and best practices notes are scattered throughout this book.

Regardless of the language or the complexity of the design, the designer must know what he is

doing and how it fits into the bigger picture.

Here are some basic points to follow:

1. ‘‘Divide and Conquer’’ – break the design into manageable pieces

a. Divide by functionality

b. Complex modules can be further broken into smaller pieces7 until basic functionality is

reached

c. Write a single sentence describing what each module at each level of hierarchy does.

If you can’t do this, you don’t have a clear enough idea of what the module should do.

Think about it some more

2. Draw a top-level block diagram for each hierarchical level in the design

a. Draw lower levels of the design hierarchy for more complex blocks

3. List the signals which move from module to module

a. For the same level of hierarchy

b. Through vertical levels of hierarchy

7 This is the beginning of hierarchical design.

Introduction and Background 7

c. Don’t just list signal names, but include types and units8

d. Choose meaningful signal names – be descriptive, complete, and unambiguous

4. Don’t start coding until the above steps are complete

Paper exercise

Consider building a simple clock which shows the date and time. Assume that somebody

else is working on the task of setting the clock and that you are responsible only for the

tracking and display of time and date.

Use the design process above to create the outline of this design.

Begin by breaking the task of ‘‘tracking and display of time and date’’ into the following

modules Track Time/Date and Display Time/Date.

Now describe the gross behavior of each module in one sentence:Time Base – This module produces a 1-Hz pulse, which forms the basis of time in this

design.

Track Time/Date – This module counts the number of 1-Hz pulses and produces a count of

the number of seconds within the day and a count of days since 1 January 2010.

Display Time/Date – This module displays the information provided by the Track Time/

Date module as HH:MM:SS and DD/MM/YY.

Display Unit – This module is responsible for physically displaying the information from

the Display Time/Date module.

The above descriptions mention what is done in each module, but further refinement is

required to identify the types of signals that pass from one module to the next.

Add signal specifications to each module in one or two sentences.

Time Base – This module produces a 1-Hz pulse, which forms the basis of time in this

design. This module is implemented external to the FPGA and produces a 50% duty cycle

square wave at 1 Hz �3 ppm9

Figure 1.3

8 If you don’t think that this is important, I’ll refer you to a certain recent Mars mission that failed because somedesigners worked in metric while others worked with the English system. The net result was not a soft touchdown, but a crater.

9 In a real-life design, this would likely be a 32768 Hz (or faster) oscillator with a divider built into the FPGA.

8 Chapter 1

Track Time/Date – This module counts the number of 1-Hz pulses and produces a count of

the number of seconds within the day and a count of days since 1 January 2010. For

simplicity, there is no need to track leap years or time shifts due to switching between

Daylight Saving Time and Standard Time. Time is passed in seconds as an unsigned

integer ranging between 0 (midnight) and 86,399 (1s before midnight). Days since

1 January 2010 is passed in days as an unsigned integer ranging between 0 (1 January

2010) and 8191 (approximately 22.5 years).

Display Time/Date – This module displays the information provided by the Track Time/

Date module as HH:MM:SS and DD/MM/YY. Information is provided to the Display Unit

as a series of seven-segment LED std_logic_vectors10 supporting 12 digits for a total of

84 segments.

Display Unit – This module is responsible for physically displaying the information from

the Display Time/Date module. It is implemented external to the FPGA and is comprised

of 12 seven-segment LED displays.

Now that each module is understood, modules requiring further clarification can be further

subdivided into a more detailed block diagram.

Time Base is most likely implemented external to the FPGA and no further refinement is

required.

Track Time/Date can be simplified into two modules, each producing one of the specific types

of output from this module.

Figure 1.4

10 A std_logic_vector is a type of signal that will be discussed when data types are introduced. For now, justconsider them as binary values.

Introduction and Background 9

Count Seconds Per Day produces an integer between 0 representing midnight and 86,399

representing 1 s before midnight. Upon reaching the terminal count of 86,399, this module

will reset the count to 0 and simultaneously issue an overflow to the Count Days module.

Count Days module increments by one on the first second of each day based on the assertion

of the overflow signal from the Count Seconds Per Day module. The count provided by

this module ranges from 0 to 8191. Upon reaching the terminal count of 8191, the count will

reset to 0 with the understanding that the date is no longer valid.

Display Unit is implemented external to the FPGA and no further refinement is required.

Next, name the signals flowing from one module to the next:

At this point we have enough information to build the outline of the design which we will

explore once we start into the VHDL section of this book.

Figure 1.5

Table 1.1

Module Signal Name Destination Description

Time Base clk1Hz Track Time/Date 1-Hz clockTrack Time/DateCount Seconds Per Day

time_of_day Display Time/DateDisplay Time

Integer 0–86,399

Track Time/DateCount Seconds per Day

overflow Track Time/DateCount Days

std_logic (1 bit)

Track Time/DateCount Days

days_since_start Display Time/DateDisplay Date

Integer 0–8191

Display Time/DateDisplay Time

LEDs_time Display Unit.time segments std_logic_vector (42 bits)

Display Time/DateDisplay Date

LEDs_date Display Unit.date segments std_logic_vector (42 bits)

10 Chapter 1