Simulators are a key aspect of the design of FPGAs. They are how we understand the behavior of our designs, check the results are correct, identify syntax errors and even check postsynthesis functionality to ensure that the designs will operate as designed when deployed in a real device. There are a number of simulators available (all the main design automation vendors provide software) and the FPGA vendors also will supply a simulator usually wrapped up with the design flow software for their own devices. This altruistic approach is very useful in learning to use FPGAs as, while they are clearly going to be targeted with libraries at the vendor’s devices, the basic simulators tend to be fully featured enough to be very useful for most circumstances. One of the most prevalent simulators is the ModelSim® from Mentor Graphics, which is generally wrapped in with the Altera and Xilinx design software kits and is very commonly used in universities for teaching purposes. It is a general-purpose simulator which can cater for VHDL, Verilog, SystemVerilog and a mixture of all these languages in a general simulation framework. A screen shot of ModelSim in use is shown in Figure 5.1 and it shows the compilation window and a waveform viewer. There are other ways to use the tool including a transcript window and variable lists rather than waveforms—useful in seeing transitions or events.

5.2.2 Test Benches

The overall goal of any hardware design is to ensure that the design meets the requirements of the design specification. In order to measure and determine whether this is indeed the case, we need not only to simulate the design representation in a hardware description language (such as VHDL or Verilog), but also to ensure that whatever tests we undertake are appropriate and demonstrate that the specification has been met.

The way that designers can test their designs in a simulator is by creating a test bench. This is directly analogous to a real experimental test bench in the sense that stimuli are defined and the responses of the circuit measured to ensure that they meet the specification.

In practice, the test bench is simply a model that generates the required stimuli and checks the responses. This can be in such a way that the designer can view the waveforms and manually check them, or by using appropriate HDL constructs to check the design responses automatically.

5.2.3 Test Bench Goals

The goals of any test bench are twofold. The first is primarily to ensure that correct operation is achieved. This is essentially a functional test. The second goal is to ensure that a synthesized design still meets the specification (particularly with a view to timing errors).

5.2.4 Simple Test Bench: Instantiating Components

Consider a simple model of a VHDL counter given as follows:

This simple model is a simple counter with a clock and reset signal, and to test the operation of the component we need to do several things.

First, we must include the component in a new design. So we need to create a basic test bench. The listing below shows how a basic entity (with no connections) is created, and then the architecture contains both the component declaration and the signals to test the design.

This test bench will compile in a simulator, and needs to have definitions of the input stimuli (clk and rst) that will exercise the circuit under test (CUT).

If we wish to add stimuli to our test bench we have some significant advantages over our model; the most appealing is that we generally do not need to adhere to any design rules or even make the code synthesizable. Test bench code is generally designed to be off chip and therefore we can make the code as abstract or behavioral as we like and it will still be fit for purpose. We can use wait statements, file read and write, assertions and other nonsynthesizable code options.

5.2.5 Adding Stimuli

In order to add a basic set of stimuli to our test bench, we could simply define the values of the input signals clk and rst with a simple signal assignment:

Clearly this is not a very complex or dynamic test bench, so to add a sequence of events we can modify the signal assignments to include numerous value, time pairs defining a sequence of values.

In our simple example, we wish to go from a reset state to actively counting and so after the rst signal has been initialized to 0, and then set to 1, the clk signal will then increment the counter. In our example we have used a process to set up the clock repetition and a separate process to initialize and then remove the reset.

While this method is useful for small circuits, clearly for more complex realistic designs it is of limited value. Another approach is to define a constant array of values that allow a number of tests to be carried out with a relatively simple test bench and applying a different set of stimuli and responses in turn. The resulting behavior can then be analyzed looking at the waveforms with measurements and markers to ensure the correct timing and functionality, as is shown in Figure 5.2.

For example, we can exhaustively test our simple two-input logic design using a set of data in a record. A record is simply a collection of types grouped together defined as a new type. With a new composite type, such as a record, we can then create an array, just as in any standard type. This requires another type declaration, of the array type itself. With these two new types we can simply declare a constant (of type data_array) that is an array of record values (of type testdata) that fully describe the data set to be used to test the design. Notice that the type data_array does not have a default range, but that this is defined by the declaration in this particular test bench. The beauty of this approach is that we can change from a system that requires every test stimulus to be defined explicitly, to one where a generic test data process will read values from predefined arrays of data. In the simple test example presented here, an example process to apply each set of test data in turn could be implemented as follows:

There are several interesting aspects to this piece of test bench VHDL. The first is that we can use behavioral VHDL (wait for 100 ns) as we are not constrained to synthesize this to hardware. Secondly, by using the range operator, the test bench becomes unconstrained by the size of the data set. Finally, the individual record elements are accessed using the hierarchical construct test_data(i).in0 or test_data(i).in1 respectively.

5.2.6 Assertions

Assertions are a method of mechanically testing values of variables under strict conditions and are prevalent in automated tests of circuits. This is a method by which the timing and values of variables (i.e., signals) can be evaluated against test criteria in a test bench and thus the process of model validation can be automated. This is particularly useful for large designs and also to ensure that any changes do not violate the overall design. It is important to note that assertions are not used in many senses to debug a model, but rather to check it is correct in a more formal sense.

For example, we can set an internal variable (flag) to highlight a certain condition (for example, that two outputs have been set to ‘1’), and then use this with an assert statement to report this to the designer and when it has occurred. For example, consider this simple VHDL code:

If the condition occurs, then during a simulation the assertion will take place and the message reported in the transcript:

This is very useful from a verification perspective as the user can see exactly when the error occurred, but it is a bit cumbersome for debug purposes. The severity of the assertion can be one of note, warning, error, and failure.

The same basic mechanism operates in Verilog, with the same keyword assert being used. If we consider the same example, the Verilog code would be something like this:

In Verilog, the severity command resulting from the assertion can be $fatal, $error (which is the default severity) and $warning.

A typical HDL such as Verilog or VHDL as a language on its own is actually very limited in the breadth of the data types and primitive models available. As a result, libraries are required to facilitate design reuse and standard data types for model exchange, reuse, and synthesis. The primary library for standard VHDL design is the IEEE library. Within the IEEE Design Automation Standards Committee (DASC), various committees have developed libraries, packages, and extensions to standard VHDL. Some of these are listed below:

• IEEE Std 1076 Standard VHDL Language

• IEEE Std 1076.1 Standard VHDL Analog and Mixed-Signal Extensions (VHDL-AMS)

• IEEE Std 1076.1.1 Standard VHDL Analog and Mixed-Signal Extensions - Packages for Multiple Energy Domain Support

• IEEE Std 1076.4 Standard VITAL ASIC (Application Specific Integrated Circuit) Modeling Specification (VITAL)

• IEEE Std 1076.6 Standard for VHDL Register Transfer Level (RTL) Synthesis (SIWG)

• IEEE Std 1076.2 IEEE Standard VHDL Mathematical Packages (math)

• IEEE Std 1076.3 Standard VHDL Synthesis Packages (vhdlsynth)

• IEEE Std 1164 Standard Multivalue Logic System for VHDL Model Interoperability (Std_logic_1164)

Each of these working groups consists of volunteers who come from a combination of academia, EDA industry and user communities, and collaborate to produce the IEEE Standards (usually revised every 4 years).

5.3.2 Using Libraries

In order to use a library, first the library must be declared: library ieee; for each library. Within each library a number of VHDL packages are defined, which allow specific data types or functions to be employed in the design. For example, in digital systems design, we require logic data types, and these are not defined in the basic VHDL standard (1076). Standard VHDL defines integer, Boolean, and bit types, but not a standard logic definition. This is obviously required for digital design and an appropriate IEEE standard was developed for this purpose, IEEE 1164. It is important to note that IEEE Std 1164 is NOT a subset of VHDL (IEEE 1076), but is defined for hardware description languages in general.

5.3.3 Std_logic Libraries

In order to use a particular element of a package in a design, the user is required to declare their use of a package using the USE command. For example, to use the standard IEEE logic library, the user needs to add a declaration after the library declaration as follows:

The std_logic_1164 package is particularly important for most digital designs, especially for FPGA, because it defines the standard logic types used by ALL the commercially available simulation and synthesis software tools and is included as a standard library. It incorporates not only the definition of the standard logic types, but also conversion functions (to and from the standard logic types) and also manages the conversion between signed, unsigned, and logic array variables.

The basic HDL design flow is shown in Figure 5.3 and, as can be seen from this figure, synthesis is the key stage between high level design and the physical place and route which is the final product of the design flow. There are several different types of synthesis ranging from behavioral, to RTL and finally physical synthesis.

Behavioral synthesis is the mechanism by which high-level abstract models are synthesized to an intermediate model that is physically realizable. Behavioral models that are not directly synthesizable can be written in VHDL and so care must be taken with high-level models to ensure that this can take place, in fact. There are limited tools that can synthesize behavioral VHDL and these include the Behavioral Compiler from Synopsys, Inc. and MOODS, a research synthesis platform from the University of Southampton.

RTL (Register Transfer Level) synthesis is what most designers call synthesis, and is the mechanism whereby a direct translation of structural and register level VHDL can be synthesized to individual gates targeted at a specific FPGA platform. At this stage, detailed timing analysis can be carried out and an estimate of power consumption obtained. There are numerous commercial synthesis software packages, including Design Compiler®, and Synplify®, but this is not an exhaustive list as there are numerous offerings available at a variety of prices.

Physical synthesis is the last stage in a synthesis design flow and is where the individual gates are placed (using a floor plan) and routed on the specific FPGA platform.

5.5.2 Synthesis Issues

Synthesis basically transforms program-like VHDL into a true hardware design (netlist). It requires a set of inputs, a VHDL description, timing constraints (when outputs need to be ready, when inputs will be ready, data to estimate wire delay), a technology to map to (list of available blocks and their size/timing information) and information about design priorities (area vs. speed). For big designs, the VHDL will typically be broken into modules and then synthesized separately. 10K gates per module was a reasonable size in the 1990s; however, tools can handle a lot more now.

5.8.1 Recursive Cut

In a recursive cut algorithm, we divide the netlist into two halves, and move devices between halves to minimize the number of wires that cross cut (while keeping the number of devices in each half the same). This is repeated to get smaller and smaller blocks.

5.8.2 Simulated Annealing

The simulated annealing method Laarhoven [9] uses a mathematical analogy of the cooling of liquids into solid form to provide an optimal solution for complex problems. The method operates on the principle that annealed solids will find the lowest energy point at thermal equilibrium and this is analogous to the optimal solution in a mathematical problem. The equation for the energy probability used is defined by the Boltzmann distribution given by Equation (5.1):

$\begin{array}{l}\hfill \mathit{P}(\mathit{E})=\frac{1}{\mathit{Z}(\mathit{T})}exp\left(-\frac{\mathit{E}}{{\mathit{k}}_{\text{B}}\mathit{T}}\right),\end{array}$

where Z (T) is the partition function, which is a normalization factor dependent on the temperature T, k_B is the Boltzmann constant, and E is the energy. This equation is modified into a more general form, as given by (5.2), for use in the simulated annealing algorithm.

$\begin{array}{l}\hfill \mathit{P}(\mathit{E})=\frac{1}{\mathit{Q}(\mathit{c})}exp\left(-\frac{\mathit{C}(\mathit{i})}{\mathit{c}}\right),\end{array}$

where Q(c) is a general normalization constant, with a control parameter c, which is analogous to temperature in Equation (5.1). C(i) is the cost function used, which is analogous to the energy in Equation (5.1). The parameters to be optimized are perturbed randomly, within a distribution, and the model tested for improvement. This is repeated with the control parameter decreased to provide a more stable solution. Once the solution approaches equilibrium, then the algorithm can cease. A flowchart of the full algorithm applied is given in Figure 5.4.

5.10.1 Initialization

Any default values of signals and variables are ignored. This means that you must ensure that synchronous (or asynchronous) sets and resets must be used on all flip-flops to ensure a stable starting condition. Remember that synthesis tools are basically stupid and follow a basic set of rules that may not always result in the hardware that you expect.

5.10.2 Floating Point Numbers and Operations

Data types using floating point are currently not supported by synthesis software tools. They generally require 32 bits and the requisite hardware is just too large for most FPGA and ASIC platforms.