Design using Standard Description Languages:Test Bench

Test Bench

The test of proper functionality of a VHDL model ideally starts during its development. To begin with, input signals like clock and data to stimulate the circuit and to produce response at the outputs are of interest. Later in the development cycle signal behavior at the output is of primary interest.

To set up a simulation environment a so called test bench, VHDL is highly suitable. The capabilities of VHDL can be used without any restrictions. From an external point of view the test bench is a closed box surrounding the object under test thus producing an autonomous system. The test bench should be a good and complete description of the environment the circuit is exposed to.

The most important characteristic of a test bench is an empty port list stated in a VHDL description one level of hierarchy above. Here the description under test is instantiated as a component. The purpose of a test bench is to produce suitable input signals and to check the outputs in a way that a time consuming visual control is not necessary. There are three parts which determine the structure of a test bench:

• A stimuli model or the definition of test vectors at the inputs;

• The VHDL description under test (device under test, DUT);

• A response model to check or store the results of the simulation.

Design using Standard Description Languages-0176

The word ‘Stimulus’ designates a sequence of test vectors assigning signal values to the VHDL description under test (DUT) at well defined points in time.

Test vectors can be built in as prepared tables in the VHDL text or have an effect at run time as a result of a calculation. An interesting alternative is to store test vectors in a file, to be read line by line during simulation (section 4.10.3). This method has the advantage that, when modifiying the test vectors, the VHDL text does not have to be compiled again. In addition different test scenarios can be realized just by a change of the file.

Design using Standard Description Languages-0177

The Response Model

An automatic simulation run should include a response model supervising all signals at the output and comparing them with expected values.

To reach that goal is far more complicated than it appears to be at a first glance. It is not only necessary to know the expected values, but also it must be known at which point in time a comparison is to be made between the actual and the expected value.

In this context there must be an answer to the following questions: at which point in time is the simulation stable, thus providing meaningful results? How many clock cycles are necessary until the outputs respond to special input stimuli in the various states the circuit can enter?

A possibility to check the results is to implement the algorithms describing the VHDL model (DUT) once again in the response model. With this a comparison of results is possible during all phases of the design cycle (fig. 4.5). This procedure is not a test of the general functionality of the circuit in its later surrounding. Apart from that there is a real danger that both models used contain similar mistakes. Because of that reason it is a good idea to describe the reverse model in a completely different manner which does not have to be synthesized.

Both methods have in common that a comparison is made generating suitable messages with the help of assertion statements.

Another possibility to check simulation results is to store the values after a close and detailed visual inspection. The values would be used as a reference for comparisons to come.

A close visual inspection is not feasible dealing with designs of a high complexity. Here, stored data could be checked using tools like C, C++, etc.

Package TEXTIO

For a flexible and universal design of a test bench file I/O functions are a must. Instead of coding stimuli or response data in the VHDL source it makes sense to read these from a file at run time. VHDL has a simple I/O system, providing line- oriented write and read operation which is the package TEXTIO located in the standard library std. Its most important sub-programs are:

Design using Standard Description Languages-0179

The procedure readline reads a complete line from textfile f and stores it in the variable 1. Looking at textline l read takes from left to right the next entry when being called and changes it to the corresponding VHDL type. After that the read pointer is set automatically to the next entry. Overloaded procedures support the most important types (see table fig. 4.24). A write step is the equivalent counterpart. The procedure WRITE passes a value to textline l and writeline writes the collected textline to the file f. The following process shows a first application of readline and writeline in a copy file function.

Design using Standard Description Languages-0180

Design using Standard Description Languages-0181Design using Standard Description Languages-0182

Comments

Post a Comment

Popular posts from this blog

Design using Standard Description Languages:The simulation model in VHDL

Image
The simulation model in VHDL After a look at concurrent signal statements in chapter 4.3, basic mechanisms of the language can be discussed in detail. Originally the language VHDL was developed for simulation only. A dis- cussion about the theory of operation of a VHDL simulator helps to understand VHDL modelling and simplifies the choice of suitable language constructs to describe hardware constructs. The topic simulation model has an emphasis on: • Driving signals; • Delta delay mechanisms; • Modelling of delay times. Drivers Every concurrent statement, including processes, causes an event responsible for the progress of a signal. Within the simulator there is a list containing points in time to schedule signal events. Such an entry in that list is called a transaction. This list is the basic information for scheduling signal values during simulation (fig. 4.22). A change of a signal value caused by an entry in that list, is called an event in that signal. If a new entry is the ...
Read more

EDA Tutorial:Place and Route in a Standard Cell Design Style

Image
Place and Route in a Standard Cell Design Style In the design of FPGA circuits, after the synthesis of the EDIF files, the compiling and programming of the FPGA device, everything is defined and the component is completely configured. With ASIC designs, there are two possible scenarios: • Delivery of the design to an ASIC provider in the form of a so called simulate d netlist (EDIF); • Place and Route of the design with one’s own tools, verification of the results, and delivering of the design as a geometrically exact GD S II File . For similar designs in industry the netlist version is frequently chosen, but here the second scenario which includes the bac k en d processing , the phys- ical design, will be demonstrated in more detail. This needs special software tools, which allow the mask design at the lowest geometry level, and tools for checking the generated geometries against the predefined design rules ( Desig n Rule Che c k , DRC ), and allow one to extract parasitics and el...
Read more

Overview of EDA Tools and Design Concepts:Major Classes of EDA Tools.

Image
Introduction In the next few chapters, we will discuss specific kinds of EDA tools. In this chapter, we provide an overview of the EDA tool world. There are several EDA-related concepts which are helpful to understand the EDA tools and the design process. These include: Design Views Hierarchy Design Chip Architecture Methodology Design Flow Tool Suites Nora of Sandbox, Inc., is meeting again with Andrea, an ASIC engineer who works for Fabless Design, Inc. Nora has asked to learn more about the use of EDA tools. Let us listen in on their discussion. Nora: Hello again, Andrea. Did you like the party the other evening? Andrea: Yes, very much. Sandbox has both outstanding tools and great parties. Nora: We seem to be continually developing new tools. I am a little unclear why that is. Tool Improvements Andrea: That's because each generation of semiconductor process improvements shrinks the size of the transistors and wires. The number of transistors and wires...
Read more