September 1, 1997

Making the jump to HDL-based programmable-logic design

Doug Conner, Actel Corp

Migrating to an HDL-based design approach requires an up-front investment of money and time to learn necessary tools and techniques. The reward, however, is easier and faster completion of PLD- and FPGA-based projects.

Making the transition from a hardware-design methodology based on schematics or simple PLD languages to one based on an HDL is a topic of interest and concern for many programmable-logic designers. Although most ASIC users have already made the jump to HDLs, the number of engineers actively using VHDL and Verilog with programmable logic is still low.

Before converting to HDL-based design, engineers and their managers need to be certain that the benefits of HDL methods will compensate the company for the cost of new tools and the extra work. Even designers who are already sold on the productivity benefits of using HDLs have problems fitting the transition into their busy schedules. It is difficult to schedule personal engineering downtime to learn to use new tools while you're working on a new design with the tools you already have.

The primary motivation for changing to an HDL-based design approach is higher productivity: You can design more equivalent gates per week with HDLs than you can with other methods. HDLs achieve this greater efficiency in several ways. For instance, HDLs allow you to use available cores, or intellectual property (IP), to embed functions into a design. Examples of typical cores include UARTs, PCI-bus interfaces, and even low-end microcontrollers, and the number of such cores is rapidly growing. The cores can have a few hundred to more than 10,000 gates, and many cores are available that you can customize to meet your design needs. The catch, however, is that vendors usually write cores in VHDL or Verilog. You need to be somewhat familiar with the HDLs to use a core and even more familiar to modify it.

Another reason for HDL efficiency is that projects you create using HDLs are easier to reuse than those done using schematics. Although HDLs and schematics both lend themselves to hierarchical-design techniques, HDLs let you build more flexibility into the design's building blocks. HDLs still let you define design components at the most basic gate level, but you can also design at higher levels of abstraction. The result is faster completion. HDL-based designs are also easier than schematic designs to retarget to other programmable-logic families. You can quickly compare cost, performance, and other variables with another product line from the same manufacturer or with another manufacturer's devices.

The growing size of CPLDs and FPGAs also requires greater design efficiency. High-end devices offer more than 50,000 gates, and lower cost devices are approaching 20,000 gates. A design with this level of gate-count complexity takes too long to complete wit hout using an HDL and other efficient means of defining the design, such as cores. Without HDLs, you may lose the fundamental PLD and FPGA time-to-market advantage over ASICs.

Once convinced of the need to add HDLs to your design, you need to decide which language or languages to learn. VHDL and Verilog both enjoy wide use. Ideally, you should learn both. The decision about which language to learn first may depend on which cores are available in a language or on which language is more popular among your peers. Although this article focuses on VHDL, it does not imply any superiority of VHDL over Verilog.

Making the transition to a VHDL-based design methodology requires you to acquire new tools, as well as the knowledge and skills to use them. Learning VHDL is perhaps the most obvious task, followed by acquiring a simulator for verifying the VHDL code and the overall project at various stages in the design. You also need a logic-synthesis tool to translate VHDL code into primitives for use in a programmable-logic-device layout, and you need the corresponding PLD or FPGA vendor-provided libraries and translators. Finally, you must learn the methodology to perform a VHDL-based design. The design methodology ties all the pieces together and might be thought of as two distinct levels. At the higher level, you learn the steps necessary to complete the design. At the lower level, you need to know what you have to type on a keyboard to make each step and substep work.

The high-level VHDL-design methodology may vary depending on the details of the project you're developing, the tools that you bring into the project, and perhaps which PLD or FPGA you use. However, any design process has the same general flow (Figure 1). Note that the block on the left side of the main path shows schematic or other design sources, such as a PLD language. These non-VHDL design blocks typically pass through the synthesis tool with the VHDL code, but VHDL synthesis does not alter them.

The output of the logic-synthesis tool is a netlist similar to the one that a schematic-design tool would generate. The netlist passes to the programmable-logic-vendor-supplied back-end tools for compilation and layout. To simplify the diagram, assume that the netlist compilation occurs in the same box as the place-and-route (or "fitting," the analogous PLD term) function occurs. Simulation provides a feedback path so that you can modify a design until the results match your design requirements. Depending on the system needs and specification flexibility, simulation results may lead to a modification of the design, the specification, or both to converge on a satisfactory compromise.

Elements of a VHDL design

Learning VHDL is in many respects similar to learning a software-programming language, such as C, Pascal, or Basic. If you know such a language, you have a good idea of what you face with VHDL. In many cases, statements, operators, and data types are functionally similar to those in software languages. Significant differences between VHDL and common software languages exist, however. VHDL lets you describe functions that operate sequentially, as do software languages, but VHDL also helps describe hardware functions that operate concurrently. These differences are not necessarily difficult to understand, but you must keep this new programming model in mind when writing VHDL code.

Another key part of learning VHDL is understanding how to combine small VHDL design units into larger ones, analogous to object-oriented software programming. Again, creating high-level designs from low level functions may be new to you, but it is not difficult. It leads to logical design structure and easier design reuse. Learning VHDL also requires learning a simulator, without which completing a VHDL-based design would be difficult, time-consuming, and frustrating.

Every VHDL design unit comprises the same basic parts (Figure 2). The first part is the entity declaration for the entity that you are completing. Think of the entity name as the name of a block in the block diagram of the system. The port declarations list the signals that enter and exit the block. After the entity declaration comes the architecture declaration, which names the architecture and binds it to an entity. Entities can have more than one corresponding architecture, but the architecture declaration can bind each architecture to only one entity.

Next, you typically find declared signals that only the architecture uses. Think of these signals as connecting components inside the design block. Following these declarations is a concurrent-statement area. The ordering of concurrent statements has no bearing on their definition. Within the concurrent-statement area are processes, and the order in which the processes appear in the concurrent statement does not affect their execution. A process executes only when a signal on the sensitivity list changes.

Listing 1 shows a simple design unit. The first two lines call out libraries that the compiler uses for both simulation and logic synthesis. The entity and2 is declared along with two inputs and one output. The architecture design1 is declared and requires no internal signals, so no local signal declarations occur. The body of the architecture contains only one concurrent statement (out1 is assigned the value of in1 and in2) and no processes.

Listing 2 shows the entity and architecture declarations for a design unit of a more complex design. The first two lines declare the libraries to use. You may also have other libraries, depending on any special functions that you use in the design. The entity name is tx_hec, and the listing shows input and output ports. You can separate declarations for each input and output or combine them, as the listing shows for the clk and reset inputs. This declaration uses std_logic, std_logic_vector, and integer logic types. Logic synthesis implements the 0-to-54 count integer as a 6-bit value. Finally, the end tx_hec statement marks the end of the entity declaration.

Following the entity declaration is the architecture declaration, which names the architecture arch1 and binds it to entity tx_hec. The architecture-declaration area also creates the type state_values and assigns it the LOAD_DATA, SHIFT_DATA, or STR_HEC value. Usually, you don't need to create individual types, but, for state machines, doing so simplifies the design. The state names in a code also make it more readable. Furthermore, when you simulate a design, the actual assigned state name instead of a numeric value representing the state appears.

Following the last signal declaration is the first statement signifying the beginning of the concurrent-statement area. The concurrent-statement area can comprise a single-line statement, such as out1 <= in1 and in2 (Listing 1), or the statement may be more complex. Often, the "meat" of VHDL code goes into processes, which handle sequential parts of the design. The process that Listing 3 shows is synchronous.

The sensitivity list appears in parentheses after the word process. In Listing 3, only clk is in the sensitivity list; therefore, this process runs only when clk changes state. The first line after the first key word checks for rising edges of clk's signal. If clk changes state with a falling edge, the remainder of the code does not execute. If, however, clk has a rising edge, the next line checks to see if the value of reset is zero. If reset is zero, the signal state takes the value of LOAD_DATA. If reset isn't zero, state takes the value of next_state. This process resets only on the rising edge of the clock. Therefore, Listing 3 generates a synchronous reset flip-flop that stores the value of state.

Listing 4 shows a process similar to the one in Listing 3 but with a few changes. The sensitivity list now includes reset and clk. Therefore, the process runs whenever either clk or reset changes state. The process tests for a reset value of zero before it tests for the rising edge of clk. You can asynchronously reset the flip-flop that is holding state's value by pulling the reset input low, regardless of the state of the clock signal. All clocked processes run concurrently when the clock changes state. If two concurrently running processes both attempt to write values to the same output or signal, a bus-contention problem occurs. For this reason, VHDL syntax generally allows only one process to assign values to each output or signal. However, one process can assign values to many signals or outputs. Other processes or concurrent statements that are not part of processes may also use assigned values.

The sensitivity list for the process in Listing 5 shows that the process runs whenever signals state, byte_cnt, or shift_cnt change value. This process defines part of a state machine. You typically create state machines in VHDL using a process with a case statement. Case statements must evaluate all possible values for a signal. In Listing 5, the signal state has only LOAD_DATA, SHIFT_DATA, or STR_HEC values. The state machine uses state and next_state, which you can think of as variables; state stores the current state of the system, and next_state stores the next state.

When state is LOAD_DATA, the logic checks to see if byte_cnt equals four. If it does, the logic assigns next_state the value SHIFT_DATA. If byte_cnt does not equal four, next_state is assigned the value LOAD_DATA. You use a similar if-then-else condition for the SHIFT_DATA state. The STR_HEC state lasts for only one cycle. When state is STR_DATA, next_state is unconditionally assigned the value of LOAD_DATA.

Listing 5 is only half of the state machine. The other half of the state machine is Listing 4, in which the process updates the value of state with the value of next_state at the rising edge of each clock cycle.

If you think of each design unit as a building block for the design, you realize that you eventually need to connect the building blocks. You do so by treating each design unit as a component of a larger design. Each instance of the component that the design unit creates has a different name. All instances of the same compo nent perform the same function, but the different names allow them to operate independently. Each instance may, for example, use independent inputs and outputs. A higher level design unit defines the connections among the instances. Think of this higher level design unit as a means of connecting all the wires among the blocks in a block diagram.

VHDL terms for components and instances are easy to understand if you use schematic analogies (Figure 3). The and2 and or2 gates on the right side of Figure 3 are components that you may replicate any number of times. The instances on the left side of the figure (the higher level design) have the unique names gate1, gate2, and gate3. Note that you may have to reassign the component ports in1, in2, and out1 to match the signals that the different instances use. Listing 6 shows how VHDL handles this simple hierarchical design.

Following the library statements is the entity declaration for top_level. The port declaration lists the four inputs and one output, corresponding to Figure 3.You can think of this port declaration as the listing of the inputs and outputs to complete the system. Next is the architecture declaration of arch1 as entity top_level. Following the architecture-declaration statement are the component declarations. The component declaration for and2 shows the input and output ports exactly as used by a lower level design unit that describes the and2 block. The component declaration for or2 is similar to that of and2.

After the last component declaration, declare any signals that are necessary to connect all the instances in the top-level diagram. For this simple design, you need only two signals because all the other signals are either inputs or outputs of the top-level design. Next are the port-map statements. These statements tell the HDL compiler how to map the local inputs and outputs of each component instantiation to the correct inputs, outputs, and signals on the top-level design. First is the instance name gate1, followed by the component name and2. The port-mapping values on the left side of the => symbol are the component input and output ports in1, in2, and out1. These port-mapping values are the same for gate1 and gate2 because both are and2 components. The right side of the => symbol shows the port or signal assignments on the higher level design. If you are using the top-level design for simulation or logic synthesis, the tools first compile the design units for and2 and or2 and then compile the top_level design unit.

VHDL descriptions become silicon reality

Simulation is the primary tool for verifying a VHDL design. When you first start learning the language, simulation helps identify syntax errors. As your skills grow, simulation will evolve into a test to see if the design functions the way it should. As a design becomes complete and you take it through logic synthesis and the place-and-route steps, simulation helps verify timing performance before exercising a silicon prototype on the system board.

You should not consider simulation a time-consuming, optional exercise. You can quickly learn to create stimulus files and to view waveform displays similar to those you might see on an oscilloscope or a logic analyzer. These simple types of simulation provide a significant benefit over no simulation at all, with a small time investment. As you gain more simulation experience and reap the benefits of design projects that subsequently go more smoothly, you'll start to identify the appropriate amount of simulation to optimize the development and debugging cycles. If you're already doing gate-level simulation, you'll probably find little difference in VHDL-based simulation.

It's possible to simulate at several levels in the design. The first opportunity is just after you write the VHDL code but before it goes through synthesis. Presynthesis simulation provides fast turnaround because it omits the added step of logic synthesis. Even if logic synthesis is fast, there is no point in running it while only functionally debugging a design. Presynthesis simulation allows you to focus on functionally defining the design without concerning yourself (yet) with optimizing the design for logic synthesis. You can optionally simulate either the individual blocks or the entire system. Also, you can mix presynthesis and postsynthesis design blocks while you work through the design.

After running the VHDL design through a logic-synthesis tool and compiling it for a PLD or an FPGA but before performing the place-and-route function, you can translate the netlist back into VHDL for second-level simulation. Estimated timing provides a rough indication of performance. When you subsequently take the design through the full place-and-route function, the design will have detailed timing values that you can use during final simulation to check the performance of the design. The price of greater timing accuracy is a significantly longer wait while the place-and-route software finishes before you can begin simulation.

Logic synthesis, which turns VHDL code into a netlist suitable for use by back-end layout, is a key tool in the design. Most logic-synthesis tools for FPGAs and PLDs are intuitive in operation and provide context-sensitive editors. Online help files provide code examples in both VHDL and Verilog to help you learn to create common hardware structures. Logic-synthesis tools also commonly provide a syntax checker and a synthesis check. These utilities can help eliminate most coding problems, such as missing semicolons and declarations and misspelled signal names, before simulation. Depending on the tools that you use, the incremental logic-synthesis time may be significant. With Synplify, a logic-synthesis tool from Synplicity (Sunnyvale, CA), a typical design unit takes less than 10 sec to compile, and a design of 5000 gates takes approximately 1 minute on a 166-MHz Pentium-based PC.

Creating synthesizable code is not difficult; however, you have no guarantee that the code will be more efficient than that of a schematic or an alternative design approach. No one has made detailed comparisons of a VHDL code vs schematic designs that would apply to your design, so comments on the inefficiency of the design process are difficult to quantify. However, fundamental design changes can result in efficiency improvements of 20% or more in some cases. Significant performance improvements are also possible. For example, if a design converts from two levels to one level of logic between flip-flops, this conversion can roughly double the clock speed.

Probably, the best approach to becoming proficient with logic synthesis is to recognize that writing efficient code takes experience. First, learn how to use the logic-synthesis tools and get advice from your PLD or FPGA vendor on the best design approaches for efficient implementation. Then get the experience.

It is possible to considerably streamline the design-synthesize-simulate loop by automating steps as much as possible. Scripts or macro files that speed repetitive steps help to develop a tight loop for running design iterations through verification. "What-happens-if-I-do-this?" experiments can build your knowledge base, so that you get good results from logic synthesis. For example, Model Technology's (Beaverton, OR) V-System simulator, which operates on a PC, provides both VHDL and Verilog capability. Macros let you easily automate simulation to minimize time and keystrokes when working through design and simulation.

Don't let roadblocks slow you down

The key to a smooth transition to HDL-based design is to avoid long delays and unproductive periods. Much of this unproductive time is the result of methodology-detail problems. On rare occasions, confusion can also develop about what should be the next step or even how to perform that step. For example, a library file may be attached to the simulator, and you don't know what instructions you need to type on the keyboard to complete the attachment. A technical-support call might give you an answer right away or in several hours or days. By working on some other part of the design, such as a design unit, during this wait, you improve productivity.

Try to keep the methodology at least one step ahead of where you are completing the work. For example, it would be unwise to wait until you are ready to simulate the full design before you try to create a top-level design unit. As soon as two design units are complete, you should begin working on the top-level design. If a problem occurs during simulation or synthesis of the top-level design, you can work on remaining low-level design blocks while you wait to receive additional information from the simulation or synthesis vendor's technical support. Think of the transition to HDL-based design as setting up a new manufacturing process. Work should progress through the manufacturing process as soon as each part of the process is up and running. It is not good enough to know how the process should work; you should evaluate the process by looking at the products coming out at the end.

Productivity and performance are natural concerns for those considering a major change in their design process. They might ask whether they can complete the design in time and whether the performance will be satisfactory. Don't think that to benefit from VHDL, you have to use it exclusively for a design, especially for the first project. Start by adding some VHDL to a design that also uses schematics, or develop a backup plan using familiar design methods, just in case. Some engineers find that within two weeks of loading the simulation and synthesis software, VHDL-based design can equal or exceed any previous efficiency rate. However, those two weeks of learning can be intense.

It always seems better to make a transition later than sooner. However, next month can turn into next year, and you might find yourself busier than ever trying to get work done with the same old design tools. A further impediment to making the transition to HDL-based design is that it is almost always possible to get your job done with existing design tools. Keep in mind, however, that it's more comfortable to migrate to an HDL on a design that you can also accomplish with schematic design tools than to wait for a project that requires you to change to VHDL or Verilog to meet your deadline. Reading a few books will help you prepare for the transition. If the opportunity is available, you should also consider taking a class. The time for the transition is never perfect, and it is best to prepare as much as possible before making the jump.

References

1. Carlson, Steve, "Introduction to HDL-based design using VHDL," Synopsys, Mountain View, CA, 1990.
2. Pellerin, David, and Douglas Taylor, VHDL Made Easy!, Prentice Hall PTR, Upper Saddle River, NJ, 1996.
3. Skahill, Kevin, VHDL for Programmable Logic, Addison Wesley, Menlo Park, CA, 1996.
4. Conner, Doug, "Making the jump to VHDL-based FPGA design," Design Supercon On-Chip System Design Conference, 1997.

| EDN Access | Feedback | Table of Contents |