Discusion y comparacion de resultados

we have a type-conflict static semantic error.

Dynamic Semantic Errors

In contrast, dynamic semantic errors can only be detected during simulation. For example, if we have a signal assignment statement where the left-hand and right- hand sides are the same type, but during execution the computed value of the right- hand side is outside the allowed range of values for that type, we have a dynamic error.

We must find and remove all syntax and static semantic errors from a design description during compilation. This is accomplished by correcting the offending statements using an editor. Afterward, dynamic semantic errors are detected and corrected during simulation.

1 . 4

VE R I F I C A T I O N U S I N G S I M U L A T I O N

Before considering the next group of design flow phases, lets examine the impor- tance of simulation. When using VHDL, a simulator is the primary development, verification, and debugging tool.

Verification Verification is the process used to demonstrate the correctness of a design. We verify that our design description meets its functional and timing specifications before the target PLD is programmed. Generally speaking, verification using simulation can show the existence of errors in a design, but cannot prove that a design is correct. The process of verification often consumes a significant percentage of the total design effort.

Simulation for Verification and Debugging

A VHDL simulator can execute a design description’s source code. The simulator allows input values to be applied to the design description. In response, the simulator computes the corresponding output values by executing statements in the design description.

When errors are encountered during a simulation, we can use the simulator’s debugging features to find and correct the source of the errors in the design description. Once modified, a design description must be compiled and simulated again to verify that the errors have indeed been corrected.

Kinds of Simulation

Simulation is performed during three different phases of the design flow (Figure 1.1.1). Each simulation phase has a particular purpose and uses a different VHDL model of the same design entity:

• Functional simulation: we simulate our VHDL design description. This simulation is performed to verify that the system we described meets the functional requirements of its specification.

• Post-synthesis (gate-level) simulation: we simulate the synthesized VHDL netlist. This netlist is a gate-level VHDL model of the synthesized logic. It is automatically generated by the synthesizer. This simulation is performed to verify that the synthesized logic is functionally correct.

• Timing (post-route) simulation: we simulate the VHDL timing model of the synthesized logic mapped to the target PLD. The VHDL timing model is automatically generated by the place-and-route tool. This simulation is performed to verify that the synthesized logic, as mapped to the target PLD, meets all timing constraints.

Later in this chapter, a separate section is devoted to each of these kinds of simulation. Prior to those sections, we consider how stimulus is provided to the model of the design entity during a simulation.

Simulation Stimulus

A simulator requires a sequence of input values (stimulus) to apply to the VHDL model being verified. If an appropriate sequence of input values is created, it can be used for all three kinds of simulation. There are three approaches to generating stimulus: interactive (manual), command line, and testbench.

Interactive Simulation

An interactive simulator allows us to manually apply a stimulus. The simulator executes the design description using the input values applied and computes the corresponding output values.

Waveform Viewer Waveforms representing the simulation model’s input and output values as a function of time are displayed using the simulator’s waveform viewer. The waveform viewer allows us to see transitions of multiple signals over time. We can zoom in or out to view selected time periods and measure the time between signal transitions. We can display bus signals as bits, hexadecimal numbers, or symbolic values. We can verify that the simulated design meets its specification by visually examining the waveforms. For simple designs, interactive simulation is adequate. For designs with more than a few inputs, applying a comprehensive stimulus interactively becomes tedious and time-consuming. Furthermore, if the design description is modified, the entire stimulus has to again be manually applied to the modified design.

Command Line Simulation

Most simulators include a command line stimulus language. Commands in the stimulus language allow us to specify input waveforms. These commands can be entered interactively or placed in a file and executed. Using commands placed in a file makes it easy to reapply a stimulus after a design is modified. However, this approach is inefficient if the stimulus to be applied is complex. In addition, a simulator’s stimulus language is simulator specific and, therefore, not portable to other simulators.

The most powerful and portable approach to generating a stimulus is to use a testbench written in VHDL. This approach is described in the next section.

Section 1.5 Testbenches 13

1 . 5

TE S T B E N C H E S

We use the next four phases to verify the functional correctness of our design description:

• Develop verification plan • Write VHDL testbench • Compile testbench • Functional simulation

Verification Plan Verification requires planning based on the system’s requirements and specification documents. The results of this planning are documented in a verification plan. For complex systems this plan is a substantial document requiring significant effort.

Even a very simple system requires some thought as to how it should be verified. Often, the greatest difficulty in conducting a successful verification is determining an appropriate stimulus to apply and the output responses to be expected. The stimulus values applied must cover all of the circumstances in which the design will be used.

Testbench A testbench is a VHDL program that applies a predetermined stimulus to a design entity during simulation. A testbench can be written to also verify the output values produced by the design entity. If there is a discrepancy between the expected and the actual output values, the testbench generates an error message. A testbench is basically a stimulus–response system.

UUT The design entity being verified is usually called the unit under test (UUT). Strictly speaking, testing refers to the process of determining whether a design was manufac- tured correctly. For example, each system manufactured would be individually tested. In contrast, verification is performed to determine whether a design meets its specifications, before it is manufactured in quantity. However, use of the term UUT, from manufacturing testing, has been carried over to verification. Other terms used are device under test (DUT), design under test (DUT), device under verification (DUV), and module under test (MUT).

A testbench is also a design entity, it consists of a testbench entity declaration and its associated architecture body. A simple testbench architecture body contains:

• An instance of the UUT

• Signals mapped to the UUT’s ports

• A process statement that applies stimulus to the UUT, via the signals

A testbench completely encloses its UUT and simulates the environment in which the design will operate.

The relationship between the half-adder UUT and its testbench is illustrated in Figure 1.5.1.

A testbench is entirely self-contained; it has no inputs or outputs. Statements in the testbench’s architecture body apply stimulus values to signals that connect to the UUT’s inputs. Other statements monitor the output values from the UUT.

UUT Models for Different Kinds of Simulations

For a functional simulation, our VHDL design description is the UUT. For a post- synthesis simulation, the VHDL netlist model (the synthesized gate-level logic) is the UUT. For a timing simulation, the VHDL timing model (produced by the place- and-route tool) is the UUT.

Half-adder Testbench

A testbench for the half adder of Listing 1.3.1 is given in Listing 1.5.1. This program contains a design entity named testbench with an architecture body named

behavior. Its entity declaration indicates that design entity testbench has no inputs or outputs.

LISTING 1.5.1

Testbench for a half adder. library ieee;

use ieee.std_logic_1164.all;

entity testbench is

end testbench;

architecture behavior of testbench is

-- Declare signals to assign values to and to observe signal a_tb, b_tb, sum_tb, carry_out_tb : std_logic; begin

-- Create an instance of the circuit to be tested uut: entity half_adder port map(a => a_tb, b => b_tb, sum => sum_tb, carry_out => carry_out_tb);

FIGURE 1.5.1

Conceptual relationship of the half-adder UUT to its testbench.

a sum

b carry_out

Half Adder _{carry_out_tb} sum_tb a_tb b_tb Testbench Stimulus Generator Response Monitor UUT

Section 1.5 Testbenches 15