For some time, designing and testing PLDs has taken place primarily in the world of hardware description language (HDL). Of course, most PLD are eventually mounted on a pc board of some sort when they're deployed in the real world. Traditionally, the design process employs HDL test benches to ensure that the FPGA/CPLD (field-programmable gate array/complex programmable logic device) will operate correctly when fed with signals from the rest of the pc board. Another method has emerged, though they're not mutually exclusive. Correct PLD operation can be confirmed by simulating the programmable device as part of the pc-board-level circuit in which it will operate.
Here's how the process works. A PLD, designed and simulated in HDL, has its symbol placed within a schematic and is simulated as part of the entire pc board. This involves using a new technology called co-simulation. Basically, co-simulation integrates the simulation data produced by HDL and Spice simulation engines and generates a single set of results, which can be viewed as waveforms, or analyzed further. Given the increasing use of FPGAs/CPLDs in today's designs, such capability provides an important new tool to PLD/pc-board engineers.
Several factors are driving the increasing use of programmable devices in today's circuit designs. One is the pressure on industrial, commercial, and consumer electronics manufacturers to miniaturize their offerings. Cell phones, wireless e-mail devices, MP3 players, and PDAs are the showcase products.
Next, as more designs become predominantly or fully digital, PLDs become feasible alternatives to pc boards, especially as they advance to handle larger circuit sizes. (State-of-the-art FPGAs provide hundreds of thousands to millions of gates.) Finally, price can be reduced. A PLD can cost dramatically less than a finished pc board. All of these facts have led to more designs employing programmable devices.
FPGAs/CPLDs imply HDLs
The large number of gates that programmable chips can now support drives down the size and cost of the design. This means, however, that the usual design methods for implementing circuits on pc boards are no longer practical for circuits destined for FPGAs/CPLDs. Most notably, schematic entry of a design with gate counts typical of FPGAs/CPLDs is impracticably cumbersome, if not impossible. Design entry is usually not schematic-based, because the size of most modern designs prevents it.
When designing with a PLD, the engineer tries to program the chip to behave in a certain way, as opposed to describing the electrical components of the PLD circuit. This difference is the fundamental reason why HDLs are utilized. They describe the behavior of a device, rather than the underlying circuitry.
Originally conceived to be behavioral-level languages, VHDL and Verilog HDL are by far the two most common HDLs. They're text-based, so for FPGAs/CPLDs, design entry is performed using a text editor instead of the typical schematic-capture tools em-ployed for pc-board designs.
For simulation, a fundamental step in the design flow of any chip, the programmable device needs to be modeled. Spice simulation works well for SSI- or MSI-level digital devices by representing them with transistor-based equivalents. As a result, it's extremely accurate. But transistor-based equivalents become unwieldy once the number of gates gets too large. This problem exists for any sufficiently large digital chip, whether it's a programmable device or a microprocessor.
Therefore, some benefits of co-simulation for PLD design also can be exploited for modeling/simulating any complex digital device within the board-level environment of which it will be a part. For this reason, FPGAs/CPLDs aren't modeled in Spice, but rather use an HDL for simulation.
As already noted, almost all PLDs today are programmed using either VHDL or Verilog HDL. Both are industry-standardized. (VHDL and Verilog are based on IEEE 1076-93 and IEEE 1364, respectively.) Consequently, each tool offers a nonproprietary method for designing with chips from a variety of different vendors. Figure 1 shows a portion of the typical VHDL source code, plus simulation results for an arithmetic logic unit (ALU).
The complexity of programmable devices, and the fact that engineers can't observe their internal circuitry, makes simulation an essential step in the design flow for all FPGA/CPLD-based designs. To perform any simulation, the device/circuit being simulated must have stimuli supplied to it. This is a VHDL test bench's purpose.
An ideal test bench lets the engineer verify the functionality of a design by applying input stimuli to the device under test (DUT) and then monitoring its response. This monitoring may be performed by collecting data to a log file for further analysis or, more typically, by plotting it to a waveform viewer integrated with the HDL simulator.
After the device itself is fully described, the test bench is created by writing additional HDL code. That code is then used to drive the simulation of the PLD acting as the DUT. In many cases, verification via co-simulation is more accurate than an HDL test bench because the latter is based on functional and timing specifications extracted from the original circuit.
For some time, designing and testing PLDs has taken place primarily in the world of hardware description language (HDL). Of course, most PLD are eventually mounted on a pc board of some sort when they're deployed in the real world. Traditionally, the design process employs HDL test benches to ensure that the FPGA/CPLD (field-programmable gate array/complex programmable logic device) will operate correctly when fed with signals from the rest of the pc board. Another method has emerged, though they're not mutually exclusive. Correct PLD operation can be confirmed by simulating the programmable device as part of the pc-board-level circuit in which it will operate.
Here's how the process works. A PLD, designed and simulated in HDL, has its symbol placed within a schematic and is simulated as part of the entire pc board. This involves using a new technology called co-simulation. Basically, co-simulation integrates the simulation data produced by HDL and Spice simulation engines and generates a single set of results, which can be viewed as waveforms, or analyzed further. Given the increasing use of FPGAs/CPLDs in today's designs, such capability provides an important new tool to PLD/pc-board engineers.
Several factors are driving the increasing use of programmable devices in today's circuit designs. One is the pressure on industrial, commercial, and consumer electronics manufacturers to miniaturize their offerings. Cell phones, wireless e-mail devices, MP3 players, and PDAs are the showcase products.
Next, as more designs become predominantly or fully digital, PLDs become feasible alternatives to pc boards, especially as they advance to handle larger circuit sizes. (State-of-the-art FPGAs provide hundreds of thousands to millions of gates.) Finally, price can be reduced. A PLD can cost dramatically less than a finished pc board. All of these facts have led to more designs employing programmable devices.
FPGAs/CPLDs imply HDLs
The large number of gates that programmable chips can now support drives down the size and cost of the design. This means, however, that the usual design methods for implementing circuits on pc boards are no longer practical for circuits destined for FPGAs/CPLDs. Most notably, schematic entry of a design with gate counts typical of FPGAs/CPLDs is impracticably cumbersome, if not impossible. Design entry is usually not schematic-based, because the size of most modern designs prevents it.
When designing with a PLD, the engineer tries to program the chip to behave in a certain way, as opposed to describing the electrical components of the PLD circuit. This difference is the fundamental reason why HDLs are utilized. They describe the behavior of a device, rather than the underlying circuitry.
Originally conceived to be behavioral-level languages, VHDL and Verilog HDL are by far the two most common HDLs. They're text-based, so for FPGAs/CPLDs, design entry is performed using a text editor instead of the typical schematic-capture tools em-ployed for pc-board designs.
For simulation, a fundamental step in the design flow of any chip, the programmable device needs to be modeled. Spice simulation works well for SSI- or MSI-level digital devices by representing them with transistor-based equivalents. As a result, it's extremely accurate. But transistor-based equivalents become unwieldy once the number of gates gets too large. This problem exists for any sufficiently large digital chip, whether it's a programmable device or a microprocessor.
Therefore, some benefits of co-simulation for PLD design also can be exploited for modeling/simulating any complex digital device within the board-level environment of which it will be a part. For this reason, FPGAs/CPLDs aren't modeled in Spice, but rather use an HDL for simulation.
As already noted, almost all PLDs today are programmed using either VHDL or Verilog HDL. Both are industry-standardized. (VHDL and Verilog are based on IEEE 1076-93 and IEEE 1364, respectively.) Consequently, each tool offers a nonproprietary method for designing with chips from a variety of different vendors. Figure 1 shows a portion of the typical VHDL source code, plus simulation results for an arithmetic logic unit (ALU).
The complexity of programmable devices, and the fact that engineers can't observe their internal circuitry, makes simulation an essential step in the design flow for all FPGA/CPLD-based designs. To perform any simulation, the device/circuit being simulated must have stimuli supplied to it. This is a VHDL test bench's purpose.
An ideal test bench lets the engineer verify the functionality of a design by applying input stimuli to the device under test (DUT) and then monitoring its response. This monitoring may be performed by collecting data to a log file for further analysis or, more typically, by plotting it to a waveform viewer integrated with the HDL simulator.
After the device itself is fully described, the test bench is created by writing additional HDL code. That code is then used to drive the simulation of the PLD acting as the DUT. In many cases, verification via co-simulation is more accurate than an HDL test bench because the latter is based on functional and timing specifications extracted from the original circuit.