Read an Excerpt

VHDL 101

Newnes

Chapter One

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 OJT 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, he 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.

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. 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.

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 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", 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 inferred 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.1).

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.

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 LUT and 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).

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 FPGA whether 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 ...

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.

(Continues...)

---

Excerpted from VHDL 101 by William Kafig Copyright © 2011 by Elsevier Inc. . Excerpted by permission of Newnes. All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.

---