Synthesis modeling techniques in VHDL

Synthesis modeling techniques in VHDL

Nowlin, Robert W


VHSIC Hardware Description Language (VHDL), a hardware description language for very high-speed integrated circuits (VHSIC), is a powerful design tool used to model, simulate, and test complicated digital circuits before device construction. It can be virtually impossible to capture the schematic design of commonly used microprocessors and Application Specific Integrated Circuits (ASICs) that contain millions of gates. However, such circuits can be simulated by first describing them in VHDL code, then synthesizing the code into its hardware equivalent. Since it is primarily a simulation tool, VHDL is not capable of projecting the actual design and thus requires a synthesizer for that purpose.

This paper illustrates several VHDL coding techniques for synthesis of common circuits such as multiplexers and state machines. Designers can use VHDL to obtain a picture of a gate-level, structural floor plan for a very complex circuit by just coding it at a purely behavioral level. This paper will provide guidelines for writing VHDL code that can be synthesized into hardware equivalents.


VHDL is an Institute of Electrical and Electronics Engineers (IEEE) standard for describing digital systems.1,2 The language helps teach a design flow methodology that students will encounter in industry, including numerous high-level digital design techniques. Most modern digital designs are computer-based, whether with VHDE, VERILOG, or some variant, and VHDE likely will be the primary design tool used by digital design engineers in the near future.3 Engineering employers are especially interested in students with knowledge of VHDE. Thus, the topic is included in most CET/EET curricula.

The VHDL language was developed in the early 1980s within the U.S. Department of Defense’s VHSIC program as a documentation language to describe digital hardware systems in a standard format.4,5,6 The language was later refined for simulation and synthesis of digital systems, becoming an IEEE standard. Today, it is used primarily as a design tool, from design entry, simulation and synthesis to documentation and high-level systems design. VHDL is used to describe circuits at various levels, including gate-level descriptions of functional blocks and high-level descriptions of complete systems.7 Standardization of analog extensions to digital systems is being developed to facilitate design of mixed-signal systems.

The compelling reasons for using VHDL in programmable logic applications include

* design portability

* reusability

* wider choice of design tools and implementation technologies

* growing complexity of designs

* top-down design, including synthesis

VHDL Synthesis

While VHDL is particularly useful for simulating and modeling digital systems, industry also considers it invaluable because of its ability to synthesize such designs. Most large semiconductor companies use VHDL to design their chips. Typically, designs are first described in VHDL, then synthesized to produce circuits that will be constructed in silicon. Complex modern circuits would be impossible to design without the use of VHDL. Industry clearly needs designers who can write and synthesize VHDL code, so helping students become fluent in this topic is quite important.

Since VHDL was developed primarily for modeling, there are a large number of constructs that, while useful for simulation, do not have any hardware equivalent. In addition, there are certain constructs with hardware equivalents that cannot be inferred by current synthesis tools. This paper will present guidelines for writing VHDL code that can be synthesized into hardware equivalents, discuss common VHDL mistakes, and provide examples and suggestions to illustrate proper coding techniques.8,9

Dos and Don’ts

There are a number of recommendations for writing good VHDL code. While these coding practices are not considered established rules, they are suggestions that can make VHDL code more readable and in some instances help optimize the synthesized design.

* A signal name must not be the same as that of a design unit, which is an actual requirement of the VHDL language. Both design and signal names are classified as identifiers, and two entities cannot share the same identifier name.

* An identifier must start with a letter, which is also a VHDL requirement.

* VHDL is not case-sensitive, so identifiers must be named carefully. For example, VOLUME and volume are identical.

* It is common practice to use lower-case letters for identifiers and upper-case letters for VHDL commands and constructs, a style that is shown in the examples in this paper.

* All processes should be labeled.

* Identifiers in ports should be grouped by their mode, namely, first all INs, then all OUTs, and finally all INOUTs.

* Each signal declaration should have its own type declaration on a separate line, even if adjacent entries are of the same type. This practice makes the code more readable and allows comments after each signal to help identify its purpose and use.

* Comments should be used liberally in the code.

* All vectors should be declared as DOWNTO, which is the vector naming convention recommended by industry.

* Global signals should be avoided, since they cannot be synthesized easily and can make the code more difficult to debug.

* Reusable code should be employed. If a specific function is needed at different places in the model, a single component that can be accessed multiple times should be used.

* Every signal that is read in a process should be included in the process sensitivity list.

* Enumerated data types should be used to represent the states of a finite state machine.

All models should employ the same data types to avoid the use of conversion functions. Synthesizable VHDL code cannot use initial values, so effective reset schemes must be incorporated. It is also good practice to have a reset associated with each memory element so that every device can be brought to a known startup value.

Coding State Machines

State machines must be carefully coded for synthesis. There are two types of synthesized state machines: counter-type state machines and one-hot state machines.


In a counter-type state machine, the state machine is synthesized into a counter that can process as many states as allowed by the number of flip-flops. For example, a five-state machine synthesized as a counter will result in a three-bit counter, representing three Hip-Hops with eight possible states. Of the eight patterns that can be shown by this counter, five represent the actual state machine and the remaining three represent invalid states. Though it is called a counter-type, the synthesized state machine docs not necessarily behave like a counter, but more like a bit pattern holder. Each count, or bit pattern, represents a different state of the machine. Just as a state machine can transition from one state to any other, the counter can go from one count (pattern) to any other count (pattern).

The synthesized counter typically has a section of combinatorial logic that controls the counter’s transition from one state to another. Since the counter-type state machine may have more possible states than the actual state machine, these state machines must be coded carefully to prevent them from going into an invalid state.


In a one-hot state machine, the state machine is synthesized into a bank of flip-Hops in which the number of flip-flops is equal to the number of states. Compared to the counter-type five-state machine that required three flip-flops, a one-hot state machine would require five flip-flops, one for each state. At any given time, only one of these flip-flops will be “on,” representing the current state of the machine. Like the counter-type machine, the one-hot state machine also includes combinatorial logic to control transitions between states.

The VHDL coding for counter-type and one-hot state machines is exactly the same. Through synthesizer settings, the designer determines whether to synthesize the state machine as a counter-type, which is slower in speed, or as a one-hot, which requires more flip-flops or area.


Just as there are recommended coding practices for the VHDL language in general, there are several important considerations when coding stale machines.

* Enumerated data types should be used to represent machine states. The standard logic type shown below is an example of an enumerated data type. Following recommended coding practices, each data type is listed on a separate line and includes comments to improve readability and understanding.

* Case statements should be used to code state machines.

* CASE statements should always end with a WHEN OTHERS clause, which insures that all states of the state machine are handled. This procedure is especially important when synthesizing into a counter-type and prevents invalid states from occurring.

* Whenever possible, the state machine should be coded as a synchronous state machine.

* A good reset scheme should be used to initialize the state machine to a valid state. Since a state machine is a feedback system, a “X” or a “U” state can prevent transition to any other state.

* The synthesized circuit should be inspected to verify that the correct number of flip-Hops have been synthesized.

* The use of latches should be avoided in the synthesized state machine. If a visual inspection of the synthesized circuit reveals a latch, there is a strong likelihood of improper coding.


VHDL synthesis tools are capable of inferring latches, flip-flops, and tri-state drivers. These elements do not need to be specifically instantiated in the code, which is a very powerful feature because it allows designers to write code that does not depend on the technology used, whether CMOS, ECL, or some other circuit design technology.

The choice between inference and instantiation is based on design goals. The use of instantiations binds VHDL models to a particular technology, and a model of the instantiated cell must be provided. Inference of a storage element makes it possible to write technology-independent code, but the range of devices that can be inferred is limited to the capabilities of the particular synthesis tool. Not all types of flip-flops or latches can be inferred. If a design uses a device that the tool is unable to infer, the designer must use instantiations. In general, synthesis tools do not infer the following types of devices:

* clock buffer

* periphery buffer

* synchronizer cells

* special flip-flops or latches

The use of inference in synthesis requires some caution. Before actually synthesizing the code, the designer must first determine how many latches or flip-flops will be inferred, and then should verify this amount on the netlist that is generated after synthesis.


A latch is inferred when a signal is assigned a value under certain conditions. In the following example, “latch_out” is a latched signal.

In this example, “latch_out” is assigned the value of “in_sig” when “enable” is 1, but no assignment is made when “enable” is 0. This condition implies that “latch_out” must store its previous value when “enable” is 0, which occurs only if “latch_out” is stored in a latch.


When inferring edge-triggered flip-flops, care must be taken to insure that the VHDL code is written so that the processes are triggered on the rising or falling edge of the trigger signal. A model of a rising edge-triggered flip-flop is shown below.

Note that the synthesis tool uses the “EVENT” attribute to distinguish between a transparent latch and a flip-flop.

This style is very compact and could be used to code almost any size multiplexer. Note that the variable “my_sel” is declared as a constrained integer to prevent the compiler from defaulting to 32-bit form during simulation and synthesis, which can place significant demands on computer resources. Also note that a variable is used to store the value of the converted signal. Variables can be used only in PROCESS statements, so this particular coding style requires the use of an explicit process.

An embedded function call can make multiplexer coding even more compact. Consider the following concurrent statement that can be used outside of a process.


Coding style for a decoder is similar to that of a multiplexer. Consider the following coding for an 8:1 decoder.


Two examples of designs coded in VHDL and then synthesized are given to help illustrate concepts described in this paper.


The up-down counter has three inputs, a reset, a direction input and a clock, and returns a 4-bit bused output, as shown in the block diagram of figure 1. The counter resets to “0000^sub 2^” immediately (asynchronous reset) when the reset signal is activated. When the reset is deactivated, the counter begins counting up or down based on the direction input. If the direction is 1, the counter will count up in the form “0000^sub 2^,” “0001^sub 2^,” and “0002^sub 2^.” Upon reaching “1111^sub 2^,” the counter resets to “0000^sub 2^.” Similarly, when the direction is 0, the counter will count down in the form “1111^sub 2^,” “1110^sub 2^,” and so on. The direction can be changed at any time during operation and the counter will count up or down from the current value. For example, assume that the direction is 1, the reset is deactivated, and the counter is counting up. Assume that when the count reaches “1101^sub 2^,” the direction is switched to 0. Counter output will be “1010^sub 2^,” “1011^sub 2^,” “1100^sub 2^,” “1101^sub 2^,” “1100^sub 2^,” “1011^sub 2^,” “1010^sub 2^,” “1001^sub 2^,” and so on. VHDL code for this counter is shown in figure 2.


Next, a carwash controller is designed, coded as a state machine, and synthesized into a one-hot state machine. As shown in the block diagram of figure 3, the carwash machine starts when a coin is deposited, then operates for a total of 15 minutes. During this 15-minute period of operation, the user may enter one of four selections as shown in table 1: rinse, soap, wash, or wax. After 15 minutes of operation, the machine shuts down automatically.

Two design assumptions are noted: (1) the coin insert mechanism will generate a pulse that is at least two clock-periods wide, and (2) the car wash controller has a 1-second clock. VHDL code for this controller is shown in figure 4.


This paper has addressed several VHDL coding and synthesis issues, including advantages of the VHDL language, recommended coding practices, methods for coding state machines, and capabilities of synthesis tools. The coding methodology discussed in this paper is generic, or tool-independent, and therefore can be applied to any VHDL software package. While the general concepts described may hold true for most synthesis tools, specific commands and usage will vary depending on the tool being used. Examples and solutions included in this paper can help students become familiar with the basic knowledge and skills needed to code VHDL models for synthesis.


1. The Institute of Electrical and Electronics Engineers. VHDL Language Reference Manual, Standard 1076-1987. New York: IEEE, 1988.

2. The Institute of Electrical and Electronics Engineers. Standard for VHDL Register Transfer Level (RTL) Synthesis, Standard 1076.6-1999. New York: IEEE, 2000.

3. Maliniak, Lisa. “A Engineer’s Guide to VHDL.” Electronic Design (October 1994): NP.

4. Jayaram, Bhasker. A VHDL Primer, Revised Edition. Englewood Cliffs, N.J.: Prentice-Hall, Inc., 1994.

5. Yalamanchili, Sudhakar. VHDL Starter’s Guide. Upper Saddle River, N.J.: Prentice-Hall, Inc., 1998.

6. Ashenden, Peter. The Student’s Guide to VHDL. San Francisco: Morgan Kaufmann Publishers, Inc., 1998.

7. Lathi, Gregg. “An Instructional Guide for Practical Design with VHDL.” Master’s diss., Arizona State University, 1995.

8. Rushton, Andrew. VHDL for Logic Synthesis. New York: McGraw-Hill, Inc., 1995.

9. Soman, Sanjiv. “VHDL Coding und Synthesis-A Lab Manual.” Master’s diss., Arizona State University East, 1997.

Robert W. Nowlin received his bachelor’s, master’s, and doctoral degrees in Electrical Engineering from the University of Washington, San Diego State University, and Texas Tech University, respectively. Dr. Nowlin has varied and extensive industrial experience and college and university teaching experience. He was formerly professor and chair of the Electronics and Computer Engineering Technology Department at Arizona State University East. Currently he is a staff development engineer with Acoustic Technologies Inc. in Mesa, Arizona.

Sanjiv C. Soman received his B.S. degree in Electronics and Communications Engineering from Regional Engineering College in Calicut, India, his M.S. degree in Electronics Engineering Technology degree from Arizona State University, and his MBA degree and E-Commerce certification from Keller Graduate School of Management. For his master’s thesis, he authored a lab manual for VHDL coding and synthesis. Currently a senior analog engineer working as the technical lead for the Signal Integrity Analysis team at Intel corporation in Chandler, Arizona, he has over six years of digital and analog hardware design experience. He has extensive experience with VHDL coding and synthesis for FPGAs. He designed and implemented the VHDL code for the FPGAs used on the validation platforms of the Intel i960RN I/O processor, i752 graphics controller, and 196Ex automotive embedded controller. He was the lead Signal Integrity Analysis engineer for the i815 chipset for the Pentium III processor and the i845 chipset for the Pentium IV processor.

Raji Sundararajan received her bachelor’s, master’s, and doctoral degrees in Electrical Engineering from the University of Madras in India, the Indian Institute of Science in Bangalore, India, and Arizona State University, respectively. She is currently an associate professor in the Department of Electronics and Computer Engineering Technology at Arizona State University East, where she teaches a spectrum of courses such as Energy Conversion and Applications, Power Electronics, Fundamentals of Digital Principles, Digital Logic Systems II, C Programming, VHDL, Transmission Lines and Waveguides, and Instrumentation Systems. She is a senior member of the Institute for Electrical and Electronic Engineers (IEEE) and a member of the American Society for Engineering Education (ASEE).

Copyright American Society for Engineering Education Fall 2002

Provided by ProQuest Information and Learning Company. All rights Reserved