April 9, 1998

Adopting VHDL for PLD design and simulation

Troy Scott, OrCAD Inc

As your designs become more complex, it becomes more efficient to use tools that allow you to design at a higher level of abstraction. Hardware-description languages, such as VHDL, are a natural next step for tackling large designs.

Time-to-market, vendor-flexibility, and design-complexity requirements have caused electrical engineers to adopt VHDL. One benefit of using VHDL for hardware design is design abstraction. Logic design using an HDL such as VHDL improves productivity by allowing you to work with logic operations and behavior rather than with the traditional approach of drawing circuit diagrams of logic gates and wires.

Using VHDL also results in improved documentation and quality. VHDL design encourages simulation. In addition to the obvious benefits of logic debugging, VHDL-testbench source code helps document design behavior. VHDL design also describes design inputs and expected outputs, making it easier to maintain the design after completion.

Another benefit of using VHDL is design portability. Perhaps the most compelling reason to adopt a standard design language is that it lets you easily migrate a design source from one PLD vendor to another. Engineers typically describe schematic-based designs with PLD-vendor-specific logic symbols. These schematics require major overhauls and component substitution if you redo the design using another vendor's PLDs.

Simulation is another benefit of using VHDL. Unlike traditional Boolean languages, VHDL is a naturally simulatable language. You can debug your design intent early in the design and continually verify that the design does what you intend it to do as it evolves from equations to gates. In addition, VHDL is a powerful way to model almost any aspect of a digital system.

A state-machine description is one of the most appropriate applications of VHDL for hardware design. The schematic equivalent of a state machine is awkward to implement and difficult to interpret because of the irregular Boolean logic required to decode next-state logic. Finite-state-machine (FSM) logic has both input stimuli and output responses, but it also has several bits of internal memory to keep track of the most recent events. A state machine uses a clock to advance one step at a time. VHDL state machines are coded with a combinatorial block that decodes and controls current states and next states. A VHDL-coded state machine also includes a register block to synchronize the machine with the system clock and to apply other controls, such as preset or reset. Each active-clock transition causes a change from the current state to the next state.

Combinatorial logic

To implement the combinatorial logic of the FSM, you use a VHDL case structure. VHDL case/when uses the same semantics to control program branching in most high-level programming languages. Listing 1 shows the general syntax for a VHDL case structure. Leveraging this expression for an FSM design, the case statement selects one of the states (branch) to be executed based on the current value of the state bits (expression). Figure 1 is a state diagram for a simple three-state FSM, along with the VHDL description of the FSM.

Sequential logic

To implement the register block of the FSM, you use a VHDL if-then structure, according to the style recommended by your synthesis tool for flip-flop inference (Listing 2).

A key consideration of FSM design is how many registered elements you need to portray the machine's current state. The traditional approach to encoding an FSM minimizes the number of flip-flops you need to represent n states. However, given the large number of registered elements in modern FPGAs, dedicating one flip-flop per state is the preferred approach to encoding large state machines. The VHDL style guides that accompany programmable-logic-vendor place-and-route software kits document this technique, "one-hot encoding" (OHE).

Designers prefer the OHE method because it requires minimal decoding to arrive at the next state of the machine. OHE increases speed and reduces signal fan-in to each FPGA hardware-logic block.

Most logic-synthesis tools allow you to control the encoding scheme that the software implements. Typically, you define the state labels as a custom VHDL data type. You then use two signal sets to portray each state. In Listing 3, VHDL declares and defines state_type to represent all state labels used in the FSM of Figure 1: init, state1, and state2. The code declares two signals, current_state and next_state, of type state_type to hold the FSM state signals.

These VHDL declarations give no explicit encoding. Instead, the system interface to the software (switches, dialogue boxes, and command-line scripts) controls the encoding scheme at compilation time. All logic-synthesis tools document how to control state encoding. 

The power of a VHDL testbench

VHDL is a powerful test-vector-generation and output-verification language. Most published technical articles regarding VHDL focus on synthesis topics and ignore the benefits gained by designers who adopt the language purely as a vehicle to create input stimuli for simulation. Even if you intend to use only schematics to design your programmable-logic parts, VHDL can help debug and confirm component behavior before you program these parts.

VHDL describes the behavior of digital hardware. This attribute provides a powerful way to describe input-signal patterns for your programmable part. The synthesis tool never interprets the testbench, which surrounds the design under test. This attribute frees you to use VHDL's expressive power, regardless of synthesis-style guidelines.

Generating clocks

Consider an example of a VHDL expression to produce a 90-MHz clock with a 50% duty cycle (Figure 2a) and the accompanying source-code sample. Assume that signal ck initializes to 0. When the simulator encounters the expression in Figure 2a, ck toggles after the specified period. This VHDL concurrent expression executes indefinitely, producing a repeating pattern of zeros and ones. If you need a variable duty cycle, you use a VHDL process to portray the difference between on- and off-times (Figure 2b). You model a sample reset pulse by the VHDL concurrent expression of Figure 2c.

You use expressions and tables to model the bus interface to the PLD under test. To quickly generate a pattern of input vectors for a bus, you use the VHDL loop statement. VHDL loop uses the same semantics to control a looping situation that you have in most high-level programming languages. Listing 4 uses a simple VHDL loop structure to generate values 0 to 7. The sequential statement within the loop converts the loop index to a std_logic_vector data type that is compatible with the interface of the PLD under test.

An alternative approach to using a VHDL expression to compute the input stimulus data is to store the data as a table either within the testbench or in a file. Listing 5 uses an array of std_logic_vector to store the bus data. You use a loop to index and apply each member of the array to the bus interface. This sample mimics the example in Listing 4, but it allows for a nonsequential pattern of input data as you customize the table.

If you've drawn a schematic, you're already familiar with "structural modeling" in VHDL. An annotated part in a schematic is equivalent to a VHDL component instance, a local wire on the schematic is a VHDL signal, the pinout of a library port is the VHDL entity interface, and so on. The terminology changes in VHDL, but the concepts are the same. The structural-modeling chapter of a VHDL textbook should be familiar ground for most electrical engineers.

Block diagrams, library parts, and VHDL components are a natural way to partition a design. However, what is the best approach to connecting them? The basic VHDL design unit is an entity/architecture pair (Listing 6). The entity section defines the interface to the hardware model and is equivalent to the pinout of a schematic-library component: signal name, port mode (such as input and output), and data type. It's easy to see the correlation between the name and type declarations of the VHDL model to a PLD schematic-library component (Table 1). In schematic editors, the most common pin types are input, output, and bidirectional. These pin types are equivalent to the VHDL port modes: in, out, and inout, respectively.

As an example, consider the FDCE flip-flop defined by the Xilinx (www.xilinx.com) XC4000E schematic library and an equivalent VHDL entity with an equivalent interface (Figure 3). The port data type, std_logic, is an extra aspect of the model that does not appear as part of the schematic part definition. The data type defines the potential signal states that the port may represent. The data type std_logic is part of the VHDL std_logic_1164 package, which most VHDL-simulation and -synthesis tools support. This database defines VHDL data types and functions for digital logic. Std_logic is a nine-state system that represents the most common digital-circuit conditions (Table 2). Each of these nine states may appear on an std_logic signal or port.

The most common logic levels are logic true/false or forcing 1/0. The std_logic convention is useful when simulating a collection of models. Signals connect the component instances, just as wires and buses connect parts on a schematic page. Similar to schematics, many circuit topologies have signals that form buses that logic circuits read from or write to. In these cases, there are potentially multiple talkers or listeners. When more than one component drives a common signal bus, contention occurs, and you must consider which drive will win in this battle for logic-state supremacy. Luckily, the std_logic_1164 also defines a table of resolution with which an std_logic data type must comply (Table 3). Std_logic accommodates single-bit quantities, and std_logic_vector accommodates buses. As a rule, use std_logic and std_logic_vector data types to define VHDL model ports.

The read/write cycles of a bus represent one of the most common system behaviors that designers want to emulate during simulation. Configurable I/O blocks or macrocells of most PLDs and FPGAs feature outputs that can both drive external circuitry and serve as input channels to the chip. You need to know how to describe these I/O blocks in schematics and VHDL. The following example is one approach to constructing these circuits for both schematic and VHDL designers. Many PLD vendors supply schematic-library bidirectional parts or the individual buffers required to construct such a part. Figure 4 shows a sample circuit with a bidirectional port (U1:BI11) from the Lattice Semiconductor (www.latticesemi.com) ispLSI/pLSI library. Listing 7 shows the equivalent VHDL RTL source code for this circuit.

Because many PLD applications require interfaces to the system bus, the VHDL testbench is an excellent vehicle to emulate the relationship between digital-system talkers and listeners. Listing 8 is an example testbench that creates the following circuit behavior:

• 0 nsec: The circuit initializes all input signals to logic-level 0, and the bidirectional buffer circuit generates a high-impedance output (Z). The circuit is effectively a listener on the data bus.

• 50 nsec: The testbench turns on the output-enable signal, out_enable, and allows the circuit state 0 created by U1:AND2 to pass through the circuit. The circuit is now talking to the bus.

• 100 nsec: The testbench releases the output-enable signal. The circuit responds by generating a high-imped-ance output.

• 150 nsec: The testbench drives the bidirectional port, bus0, to 0. This aspect of the testbench emulates an external talker submitting data to the bus. The circuit responds by feeding data back to the internal gate, U3:OR2, which eventually supplies data to the output port, o0.

• 200 nsec: The testbench drives the bidirectional port, bus0, to 1. Again, the circuit responds by feeding data back to the logic's internal circuitry.

• 250 nsec: The testbench drives the bidirectional port, bus0, to 0. The circuit responds by feeding data back to the logic's internal circuitry.

• 300 nsec: The testbench drives the bidirectional port, bus0, to a high-impedance state. This aspect of the testbench emulates the unused state of the system bus.

• 350 nsec: The testbench turns on the output-enable signal, out_enable, and allows the circuit state 1 created by U1:AND2 to pass through the circuit.

• 400 nsec: The testbench releases the output-enable signal. The circuit responds by generating a high-imped-ance output.

In a paper written by engineers at Hughes Aircraft Co (Westchester, CA), the authors describe the design method used by a team to develop the winning VHDL-based application of the VIUF (VHDL International Users' Forum) '97 design contest (Reference 1). The process used by Hughes has evolved over the past five years and the company has successfully employed it in a variety of programs from a multiASIC space-based surveillance system to an FPGA-based video-processing subsystem.

Hughes divides its VHDL system design into three main tasks (Figure 5). The company splits the design-synthesis phase into four subtasks covering VHDL coding through synthesis-results analysis (Figure 6). The primary goals of development efforts at Hughes are to reduce design-cycle time and to minimize design cost. Given VHDL as the vehicle for describing systems, Hughes establishes four design phases to help reduce design-cycle time: design reuse, top-down design entry, "real-world" testbenches, and design error containment.

To maximize VHDL reuse, you must keep reuse in mind throughout the design process. You must thoroughly comment the design unit, give meaningful names to signals and ports, and create a testbench to document design functionality. Other techniques that ease VHDL-design-unit portability include using standard data types, operators, and attribute-free source code.

With top-down design, the design should flow naturally from requirements and decompose into hierarchical subunits. This flow ensures that the design meets all design requirements and that you can trace it.

A robust testbench makes a design simulation that is as close to the operating environment as possible. The testbench represents the design's interface to other digital system components. A robust interface model serves as a natural functional specification of the design unit because it may document software test vectors: input stimuli and expected outputs. The model also qualifies the data type and ranges allowed for information that flows in and around the design unit. You should also be aware of the delays that the circuit introduces, which are created by synthesis or timing analysis of the placed and routed circuit. A robust testbench anticipates the signal latency caused by potentially hundreds of internal logic levels. The testbench supplies data at a rate such that it holds data stable before clocking and that output checks anticipate output signal skew.

In general, when trying to contain design errors, the least expensive fix for design problems occurs early in the design's development. 

Reference 1 documents a high-level methodology and justification for hardware development at Hughes Aircraft with VHDL. The authors base their advice on experience that other designers can use to improve productivity at their own companies. Another key design-productivity trick is to record errors during the design. This record of experiences allows engineering managers to better forecast the schedule of development efforts and to back up their projections with data.

References

1. McCoullough, Mike, and W Lee, "Processes, Metrics, and VHDL," VIUF Spring 1997 Conference Notebook of Sessions, pg 87.

2. Rushton, Andrew, VHDL for Logic Synthesis, McGraw-Hill Book Co Europe, Berkshire, UK, 1995.

3. Cohen, Ben, VHDL Answers to Frequently Asked Questions, Kluwer Academic Publishers, Norwell, MA, 1996.

4. Bhasker, J, A VHDL Primer, Prentice Hall Series in Innovative Technology, Englewood Cliffs, NJ, 1995.

5. OrCAD Express for Windows, VHDL Style Guide, online help system, www.orcad.com.

| EDN Access | Feedback | Table of Contents |